ここを見ると、システムのタイムゾーンを推測しようとする PHP 5.3 のコードを見ることができます。それほど多くはありませんが、問題が表面化しているように見える場所であるため、推測を削除する理由は主に DST に関連しているようです.
推測プロセス全体の内訳は次のようになります。
- すでにグローバルに定義されているかどうかを確認します (php.ini または以前の推測) (行 851-853)
- 環境変数を確認してください
TZ
(私の経験ではほとんど定義されていません) (行 855-858)
- php.ini から確認
date.default_timezone
します (既に定義されているはずの特殊なケース) (860 ~ 872 行目)
- と を比較して、システムからタイムゾーンを推測してみて
time()
くださいlocaltime()
。この呼び出しのスレッド化されたバージョンで問題が発生する可能性があるため、タイムゾーンの設定はオプションであると仕様に記載されているようです (行 873-890)。
- Win32: WinAPI 関数
GetTimeZoneInformation()
を呼び出して、システムのタイム ゾーンを判別してみてください (893 ~ 928 行目)
- Netware:
_timezone
定義されている場合は値を確認します (行 929-937)
- 上記のチェックのいずれも成功しなかった場合は、UTC にフォールバックします
推測することしかできませんが、そもそも推測であり、常に信頼できるとは限らないため、削除しただけかもしれません。
また、PHP の人気により、顧客がサーバーと同じタイムゾーンにいないことが多い Linux ベースの共有ホスティング プランのほぼすべてにインストールされているため、それらの人々のためにサーバーのタイムゾーンにフォールバックすることは、デフォルトで UTC を使用することに勝るものはありません。そうすると、これらの顧客が SO に来て PHP の時間が間違っている理由を尋ねなければならないので、混乱を招くだけです。
私はCと標準に十分に精通していませんがlocaltime
、マルチスレッドコードに問題があるか、場合によっては利用できないことに基づいてタイムゾーンを推測しているようです。Windows 以外のプラットフォームでは、これがタイムゾーンを決定するための最良の方法であるため、マルチスレッド PHP で何も返さないか、問題を引き起こす可能性が半分あるとしたら、意味がありません。
もちろん、タイムゾーンとオフセットが時期に基づいて異なるいくつかの場所では、DST の問題があります。
それが役立つことを願っています。