Подтвердить что ты не робот

Класс DateTime против встроенных функций даты PHP

Класс DateTime, безусловно, имеет несколько удобных методов и в целом превосходит встроенные функции даты PHP, такие как strtotime, mktime и strftime (и многие другие). Но есть ли какой-то недостаток или причина, почему я не должен использовать это?

Единственная причина, по которой я могу придумать, состоит в том, что создание целого экземпляра класса может быть более дорогим, чем просто использование функции.

  • Ты бы согласился с этим?
  • Имеет ли смысл вообще использовать объект DateTime для простых вещей?
  • Есть ли другие недостатки?

Кажется немного запутанным переключаться между этими двумя вариантами все время, поэтому я хотел бы получить разрешение, что я предпочел бы делать.

Вот два примера моего решения:

  • Преобразование даты в локализованное значение
  • Расчет времени между двумя датами
4b9b3361

ОТВЕТЫ

Ответ 1

Если вы беспокоитесь, что создание экземпляра класса дорого и что это будет мешать производительности, то, боюсь, вы лаете на неправильном дереве. Не следует рассматривать вопрос о том, следует ли использовать проверенный подход OO, где это имеет смысл. Если имеет смысл использовать класс DateTime для выполнения определенных расчетов по дате, используйте его. Это не дорого до такой степени, что ваше приложение будет чувствовать это, если вы не сделаете что-то сумасшедшее, например, создание 1 миллиона объектов DateTime.

Причина, почему DateTime замечательна, заключается в том, что она облегчает заботу о летней экономии, указав часовой пояс при создании объекта. Также легко получить различия между датами или получить интервалы между разными объектами. Это в основном сокращает количество беспокойства и кодирования (но я признаю, что это неправильно иногда, надеюсь, он будет рассмотрен в версии 5.4 PHP).

Нижняя строка - я всегда буду использовать ее.

Ответ 2

Для записи я сделал ошибку, чтобы использовать класс DateTime. Это была большая ошибка. Хотя у него есть некоторые приятные функции, но это не стоит усилий. Я объясняю:

Скажем, что у вас есть форма (с устройством выбора даты), и вы храните в базе данных, тогда у вас есть 3 формата для представления даты.

  1. Внутренне переменная имеет тип DateTime()
  2. Визуально переменная, отображаемая пользователю, представляет собой строку формата dd-mm-yyyy или mm-dd-yyyy (это зависит от региональных настроек)
  3. В базе данных сохраненная переменная также является строкой формата yyyy-mm-dd (ANSI)

Итак, я имею дело с 3 различными видами представления для одного и того же типа данных

Кроме того, скажем, что вы хотите сериализовать (json, xml или такой), это сериализация:

object(stdClass)#1 (1) {
  ["field1"]=>
  object(DateTime)#2 (3) {
    ["date"]=>
    string(26) "2018-12-02 09:14:09.216273"
    ["timezone_type"]=>
    int(3)
    ["timezone"]=>
    string(30) "America/Argentina/Buenos_Aires"
  }
}

Это настоящая боль, чтобы попытаться сериализовать. Моя альтернатива проста, чтобы сохранить любую временную дату в виде строки, и я буду преобразовывать ее в DateTime, только если это необходимо.

object(stdClass)#3 (1) {
  ["field1"]=>
  string(19) "2018-12-02 09:14:09"
}

Ответ 3

Использование DateTime() делает код более читабельным по сравнению с процедурным подходом функций strtotime() и т.д.

if( strtotime( date( 'm/d/Y', strtotime( $strStartDate ) ) ) > strtotime( date( 'm/d/Y', strtotime( '+6 month', strtotime( $strEndDate ) ) ) ) ) {

против

if( new DateTime( $strStartDate ) > ( new DateTime( $strEndDate ) )->modify( '+6 month' ) ) {

На Windows 64-битных машинах разработки PHP все еще 32-битный. Это даст ваши странные результаты для дат после пятницы, 13 декабря 1901 20:45:54 UTC до вторника, 19 января 2038 03:14:07 UTC

echo ( new DateTime( '20 Jan 2038' ) )->format( 'm/d/Y' ) . PHP_EOL; // gives 01/20/2038
echo strtotime( '20 Jan 2038' ); // returns false

https://www.php.net/manual/en/function.strtotime.php#refsect1-function.strtotime-notes

Примечание. Допустимый диапазон отметок времени обычно составляет от пятницы, 13 декабря 1901 года, 20:45:54 UTC до вторника, 19 января 2038 года, 03:14:07 UTC. (Это даты, которые соответствуют минимальным и максимальным значениям для 32-разрядного целого числа со знаком.) До версии PHP 5.1.0 не все платформы поддерживают отрицательные временные метки, поэтому ваш диапазон дат может быть ограничен не ранее эпохи Unix., Это означает, что, например, даты до 1 января 1970 года не будут работать в Windows, некоторых дистрибутивах Linux и некоторых других операционных системах. Для 64-битных версий PHP допустимый диапазон метки времени фактически бесконечен, поскольку 64-битные могут представлять примерно 293 миллиарда лет в любом направлении.

Я не уверен, что летнее время правильно обрабатывается с помощью встроенных функций даты и времени.

Я бы порекомендовал использовать функции DateTime() над собственными функциями даты и времени.