Класс DateTime и нативные функции даты в PHP - PullRequest
Новая
       8

Класс DateTime и нативные функции даты в PHP

21 голосов
/ 22 декабря 2011

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

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

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

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

Два примера для моего решения:

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

Ответы [ 3 ]

43 голосов
/ 22 декабря 2011

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

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

Итог - я всегда буду его использовать.

0 голосов
/ 02 мая 2019

Использование 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' ) ) {

На 64-битных компьютерах под управлением Windows 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 () вместо собственных функций даты и времени.

0 голосов
/ 02 декабря 2018

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

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

  1. Внутренне переменная имеет тип DateTime ()
  2. Визуально переменная, отображаемая для пользователя, представляет собой строку в формате дд-мм-гггг или мм-дд-гггг (зависит от региональных настроек)
  3. В базе данных сохраненная переменная также является строкой в ​​формате гггг-мм-дд (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"
}
...