Поскольку большую часть времени я провожу с php и mysql или pgsql, я буду использовать DateTime в качестве общего слова для API даты. В php нет «Date», «Time», «DateTime» и «DateTimeOffset»,
Поскольку я разрабатываю веб-приложение все более и более тщательно, я использую DateTime большую часть времени, но иногда мне интересно, действительно ли это то, что я хочу. например, бывает, что я просто хочу отображать сегодняшнюю дату (например, когда я хочу сохранить форум или сообщение в блоге), нет никаких вычислений, фильтра нет, нет итерации … Итак, почему я использую \DateTime над функцией date() ?
Я видел эту тему, которая дает некоторое простое описание преимуществ каждой технологии.
Но на этот вопрос он не отвечает. Это действительно потеря, чтобы выбросить еще 2 байта в объект DateTime в PHP и другие 2 байта в моей базе данных, поскольку он позволяет мне использовать API DATE_INTERVAL (в php это DateInterval ) и IntlDateFormatter.
Более того, в этом сообщении говорится, что unix_timestamp зарезервирован с 1970 года. Но это нелогично, и некоторые тесты доказывают это:
echo date('d/m/Y',time(-1));
эхо-31/12/1969 '! И это логично. 32 бита unsigned int идут от 0 до 4 294 967 295 и в 68 лет всего лишь 2 миллиарда секунд, поэтому int подписан и «отрицательная метка времени» должна существовать!
Другой считает, что это действительно важно для меня, и это заставляет меня выбирать DateTime каждый раз, что я хочу иметь дело с датами, а не целыми числами. DateTime – это дата, временная метка – нет! Единственный смысл, который я нашел в timestamp, – это время, когда я захотел пометить имя файла, потому что в этой метке времени времени есть метка времени …
Тем не менее, все еще проблема: обработка часового пояса. Поскольку MySQL и другие не обрабатывают часовой пояс при хранении дат как DateTime, на данный момент я использую интеграцию TimeZone в качестве escape-части «фильтра при выходе»,
$toStoreDate = new \DateTime($_POST['date'],new DateTimeZone('UTC')); $dao->exec('INSERT INTO mytable(mydate) VALUES (\''.$toStoreDate->format('Ymd h:i:s').'\')'); $toDisplayDate =new \DateTime( $dao->query('SELECT mydate FROM mytable') ->fetch(DAO::FETCH_ASSOC)['mydate']); $toDisplayDate->setTimeZone(new DateTimeZone('myLocal'));
Правильно ли это? Не лучше ли хранить простую временную метку, а затем получить хорошее местное время?
Итак, вот обобщение вопроса:
Как сказано в комментарии, я считаю, что это в основном зависит от личных предпочтений. На мой взгляд, использование временной метки Unix и «устаревших» интерфейсов, отличных от OOP, не способ сделать это в современном мире, например, мы не делаем (читаем: не следует) с использованием типа данных INT в нашей базе данных для хранения дат в формате Timestamp Unix вместо этого мы должны использовать собственный тип базы данных, который обычно является типом DATE или DATETIME который почти всегда взаимодействует с объектом DateTime PHP (и другими языками), когда дело доходит до стандартных преобразований.
Чтобы немного рассказать о том, что я подразумеваю под стандартными преобразованиями: когда вы используете MySQL и отбрасываете значение в PHP, вы получаете строку даты в формате ISO, из которой класс DateTime анализирует в своем конструкторе, предоставляя вам немедленно используемый объект. Напротив, чтобы пойти по маршруту отметки Unix, вам нужно будет использовать strtotime , а затем date чтобы получить его в любом формате, который вы хотите изначально.
Я уже говорил о взаимодействии между нашими системами PHP и системами .NET. Хотя особых проблем, вызванных использованием временной метки, нет, это просто не практическое решение, так как снова мы используем базу данных, которая возвращает значение DateTime, которое может быть отправлено прямо по трубе. Если бы мы преобразовали это в временную метку unix для внутреннего использования в PHP, мы также должны были бы ее отменить, если бы мы отправили ответ или отправили ответ на .NET-приложение (или я просто скажу API в этом случае), это временная метка и конвертировать ее в конец. Используя DateTime по всем направлениям, это облегчает необходимость каких-либо преобразований, и весь процесс разработки проще.
Наконец, чтобы добавить все это, как вы упомянули в своем посте, вы можете использовать блестящие элементы, такие как DateInterval , упростить время, упростить манипуляции и упростить форматирование и т. Д., Когда вы используете DateTime и связанные с ним объектно-ориентированные партнеры в преступлении. Это просто процесс разработки в моих глазах.
Я не верю, поскольку изначально я сказал, что есть «правильный» ответ на этот вопрос, а скорее личное предпочтение, основанное на вашем собственном стиле кодирования, и комментарии выше отражают мою.
Является ли еще 2 байта DateTime потерей в действительно простом использовании API (только отображение)
Настало время отказаться от unix_timestamp?
Да 🙂
Не лучше ли хранить простую временную метку, а затем получить хорошее местное время?
См. Комментарии выше в базе данных, это не «родной» для использования отметки времени Unix для этой цели IMO. Вы можете просто позвонить ->getTimezone и сохранить это в базе данных, а затем использовать ->setTimezone когда вы вытащите его обратно.
Не точный ответ на ваш вопрос, но я бы выбрал Timestamp над DateTime , потому что я верю, что работа над значением Integer намного экономичнее (измеряя время обработки процессора), а обрабатывая значения DateTime .
Я чувствую себя очень комфортно, когда у меня есть Numbers на Binary Machine , вместо того, чтобы иметь Strings или Objects .
Человек против машины
Что касается понимания , я бы сказал, когда я пишу программу для компьютера, я бы подумал, что я делаю это для Machine чтобы работать над этим, однако, если абстракция над этим слоем может помочь людям понять что лучше, почему бы нам не использовать это, когда Performance не проблема?
Я не могу вспомнить, кто сказал или где я это слышал, но кто-то сказал что-то вроде « People hate Computers, but they should hate Programmers , и я полностью согласен с этим. Поэтому, как человек, я все еще уважаю эту машину и постараюсь сделать программы, которые более понятны для компьютеров. 🙂
Обновить:
Чтобы представить это лучше, представьте себе, что у нас есть программа для работы с «Датами», обрабатывающая 10 000 раз в минуту, не так ли?
// it LOOKS Better $date = new DateTime(); $date->setDate(1986, 3, 24); // March 24, 1986 echo $date->format('Ym-d'); // it WORKS Better echo date("Ymd", mktime(0, 0, 0, 3, 24, 1986)); // March 24, 1986
Скажем, я должен смотреть этот код на час в неделю, и пусть говорят, что есть 10 000 человек, которым они должны заниматься этим 24/7/365, и, конечно, я не собираюсь с этим справляться, это задача для машина.
Кстати, я бы сказал, что если Performance не проблема, то почему мы не делаем ее более понятной для программистов? Если нам нужно получить максимальную отдачу от этого, дайте программистам взглянуть на код, который Works лучше, а не Looks ! 🙂