Почему PHP считает плохую идею полагаться на системный часовой пояс?

Я немного недоволен обновлением часового пояса PHP. Мне очень нравится, что все остальное в моей системе доверяет тому, что я правильно соблюдаю системный часовой пояс. Возможно, могут быть случаи использования, когда было бы полезно настроить PHP по-разному, но почему PHP предупреждает меня о том, что использование моего часового пояса небезопасно?

Предупреждение: date(): не безопасно полагаться на настройки системного часового пояса. Вы должны использовать параметр date.timezone или функцию date_default_timezone_set().

ОТВЕТЫ

Ответ 1

Вот что говорят об этом разработчики PHP (в обсуждение):

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

Derick Rethans является автором этого коммита, который превратил date_warning из E_STRICT (в PHP 5.2-) в E_WARNING (PHP 5.3 +).

В этом же обсуждении есть довольно звуковое (но явно неудобное) решение этого, примененное MediaWiki:

Собственно, разумное значение по умолчанию - это то, что guess_timezone() уже делает, кроме без предупреждений. Вы можете получить это поведение, например,

date_default_timezone_set( @date_default_timezone_get() );

в верхней части вашей программы. Что делает MediaWiki (за исключением изменяя error_reporting вместо использования @). Мы украли эту идею из другое веб-приложение. Это более удобно, чем дублирование функциональность guess_timezone() в приложении.

Это Derick прерогатива раздражает всех пользователей до смерти предупреждений, поскольку его способ указать на его отвращение к состоянию ОС поддержка запроса системного часового пояса. То вознаграждение, которое мы ему даем для написания большого количества кода даты/времени.

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

  • чтение часового пояса с помощью функции date_default_timezone_set() (если есть)
  • чтение переменной окружения TZ (если не пустой) (до PHP 5.3.0)
  • чтение значения параметра date.timezone ini (если установлено)
  • запрос операционной системы хоста (если поддерживается и разрешено ОС)

Ответ 2

Потому что Дерик так сказал. Вот почему. Эта внутренняя цепочка списка рассылки расскажет вам все о логике этого решения. Предупреждение date.timezone является постоянным раздражением для всех, кто использует PHP в качестве языка программирования, а не как замену для знания того, как писать код.

В частности, это поведение меня заводит. Я обычно не злоупотреблял бы системой SO Q & A, чтобы выпустить ее, но это предупреждение заставляет меня бананы. Кроме того, это 1 апреля, так почему бы и нет?

Ответ 3

1) с использованием системы Timezone - это основные издержки производительности.

2) реализации базы данных TZ разными поставщиками имеют исторические проблемы с множеством функциональных проблем

3) есть проблемы вокруг интеллектуальной собственности данных. Его угроза претензий и за счет защиты их, что подрывает такие проекты, - недействительность претензии. Дело 2011 года было урегулировано вне суда, что означает, что этот вопрос был разрешен только в случае истца, а не для решения каких-либо будущих задач.

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

Ответ 4

PHP часто используется людьми, которые должным образом не поддерживают свои системы или работают в системах других людей (общий хостинг). Если вы должным образом поддерживаете свою систему, настройка по умолчанию часового пояса PHP по-разному проста.