私たちの惑星地球では、同時に、惑星のさまざまな地理的ポイントが1日のさまざまな時間を持つことができます。これは、私たちの世界が回転するジオイドであり、平らな円盤ではないという事実の結果ですが、太陽系には太陽が1つしかありません。学校は誰もがタイムゾーンについて知っているので、私たち全員が実際の生活の中で出会ったのです（「モスクワ時間-15時間、ペトロパブロフスク-カムチャツキーで-真夜中」、長距離便の時差ぼけなど）。残念ながら、タイムゾーンは世界の物理的特徴に部分的に基づいているだけであり、コンピューターの計算では、他の、時には予期しないニュアンスを考慮する必要があります。

*「そしてそれでも回転します！」-ガリレオ・ガリレイが言ったキャッチフレーズ。残念ながら、このローテーションは、タイムゾーンに関するこれらすべての「すばらしい」問題につながります。

この記事とガリレオの共通点は何ですか？はい、一般的には何もありません。私たちの世界が宇宙の中心であったとしても、タイムゾーンに対処する必要があるのではないかと心配しています。タイトルは私の見落としであると見なしますが、修正はできません（できますが）。

タイムゾーンとは何ですか？

あなたのタイムゾーンは何ですか？「UTC + 3」と答えた場合-これは現時点でのみ正しい答えになりますが、一般的にこの記述は間違っています。タイムゾーンのデータベースを見ると、たとえば、ベルリンとウィーンのオフセット「UTC + 1」にもかかわらず、タイムゾーンが異なることがわかります（「ヨーロッパ/ベルリン」と「ヨーロッパ/ウィーン」）。なぜそう理由は、彼らが歴史の異なる時期に異なる夏時間（DST）を持っていたからです。今日、これらの2つの国とこれらの2つの都市が同じDST規則を持っているとしても、100年前はそうではありませんでした。たとえば、オーストリアとドイツでは異なる時間帯に夏時間はありませんでした。1920年以降のオーストリアと1918年以降のドイツでは、両国は同じDSTルールを使用していました（驚くことではありません）終わりが再び同期しなくなります。ドイツは1949年に夏時間を取り消して1979年に再び導入し、オーストリアは1948年に夏時間を取り消して1980年に再び導入しました。最悪の事態は、同じ夏時間にも同意しなかったことです。

そして、これは世界中で起こっています。コンピューターコンピューティングの場合、夏時間への移行は大きな問題です。なぜなら、時間は連続的な運動に乗っていると想定しているからです。夏時間では、毎年2回繰り返される時間があります。ログに書き込むときにローカル時間を指定すると、ソート中に行の順序に違反する可能性があります。

pytzドキュメントからの引用：

そのため、たとえば、2002年の米国/東部のタイムゾーンでは、DSTの有効期間の終了時、10月27日、01：30の時間は2回来ましたが、4月7日のDSTアクションの開始時は02:30の時間ではありませんでした。 02:00に時計が1時間進められました。

ただし、タイムゾーンには夏時間の規則だけが保存されるわけではありません。一部の国では、DSTを変更せずにタイムゾーンを変更する場合があります。そのため、たとえば、1915年にワルシャワは中央ヨーロッパの時間になりました。その結果、1915年8月5日の午前0時に、時計は24分前に切り替えられました（夏時間はワルシャワで動作します）。

一般に、タイムゾーンではさらに多くの問題が発生します。午前0時と日の出時刻の同期により、日中のタイムゾーンが異なる国が少なくとも1つあります。

常識はどこですか？

常識があり、協定世界時（UTC）と呼ばれます。 UTCは、夏時間のないタイムゾーンであり、過去の変更はありません。ただし、地球は回転ジオイドであり、世界には制御できないものがあるため、修正秒（うるう秒）の問題があります。 UTCが修正秒を考慮するか（不規則であるため、計算時に考慮するのが難しい）、そうでないか（各タイムゾーンにはUTCとの差が数秒あります）は、私が知る限り、まだ決定されていません。

それにもかかわらず、現在、UTCは最も安全なオプションです。 UTCから、任意のタイムゾーンの時刻をローカル時刻に変換できます。上記の逆変換は不可能です。

だから、ここにあなたを失望させないだろうという大まかな経験則があります：

常にUTCで時間をかけて保存して作業します。元のデータを保持する必要がある場合は、個別に書き込みます。現地時間とタイムゾーンを保存しないでください！

問題は何ですか？

一般に、この記事は終了しているはずです。しかし、残念なことに、Pythonでプログラムを作成する際に留意すべき点がいくつかあります。これは、言語の実用化について誰も考えなかった古代の建築ソリューションの遺産です。動機は重要でしたが、常識は重要ではありませんでした。

ある晴れた日、Python標準ライブラリのdatetimeモジュールのアーキテクチャについて次の決定が行われました。

タイムゾーンは頻繁に変更されるため、datetimeモジュールにはタイムゾーン情報を格納しないでください。
一方、datetimeモジュールはタイムゾーン情報（tzinfo）を追加する機能を提供する必要があります。
以下のオブジェクトをdatetimeモジュールに実装する必要があります：date、time、date + time、timedelta。

残念ながら、何かがおかしかった。主な問題は、タイムゾーン情報（tzinfo）が追加された日時オブジェクトがタイムゾーンなしで日時オブジェクトと対話しないことです：

>>> import pytz, datetime >>> a = datetime.datetime.utcnow() >>> b = datetime.datetime.utcnow().replace(tzinfo=pytz.utc) >>> a < b Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can't compare offset-naive and offset-aware datetimes

日時オブジェクトにタイムゾーン情報を追加する必要があるひどいAPIに目をつぶると、まだ問題があります。 Pythonで日時オブジェクトを使用する場合、遅かれ早かれ、プログラムのすべての場所でtzinfoを追加または削除する必要があります。

もう1つの問題は、Pythonで現在時刻を使用してdatetimeオブジェクトを作成する2つの方法があることです。

 >>> datetime.datetime.utcnow() datetime.datetime(2011, 7, 15, 8, 30, 55, 375010) >>> datetime.datetime.now() datetime.datetime(2011, 7, 15, 10, 30, 57, 70767)

一方はUTCで時刻を返し、もう一方はローカル時刻を返します。ただし、datetimeオブジェクトは「ローカル時間」を教えません（少なくともバージョン3.3のPythonまではタイムゾーン情報がないため）。これらのオブジェクトのどれがUTCで時間を保存しているかを知る方法はありません。

UNIXタイムスタンプをdatetimeオブジェクトに変換する場合、datetime.datetime.utcfromtimestampメソッドを使用する場合も注意が必要です。これは、ローカル時間でタイムスタンプを取得するためです。

日時ライブラリは、tzinfoを追加してもまったく役に立たない日時オブジェクトも提供します。このためには、日付を知る必要があるため、時間オブジェクトを別のタイムゾーンに転送することはできません。日付オブジェクトは通常、ローカルタイムゾーンでのみ意味を持ちます。今日の私にとっては昨日でも明日でもいいからです。すばらしいタイムゾーンの世界に感謝します。

それでは、専門家の推奨事項は何ですか？

今、私たちは誰が責任があるのかを知っています。しかし、何をすべきか？過去の過去の日付を扱う場合にのみ現れる理論上の問題を無視する場合、いくつかの推奨事項があります。過去の日付を処理する必要がある場合は、代替モジュールmxDateTimeがあります。これは合理的に設計されており、さまざまなカレンダー（グレゴリオ暦およびユリウス暦）をサポートします。

プログラム内でUTCを使用する

現在の時刻を取得する必要がある場合は、常にdatetime.datetime.utcnow（）を使用します。ユーザーから現地時間を取得する場合は、常にすぐにUTCに変換します。明確な変換を行うことが不可能な場合、これについてユーザーに通知し、盲目的に時間を推測しようとしないでください。サマータイムへの移行中および復帰中に、iPhoneが何度も時刻を正しく設定できませんでした。クロックを変換する必要があるため、いつこれを行うかを知っています。

タイムゾーンで時間を使用しないでください

常にタイムゾーン情報をdatetimeオブジェクトに追加するのは良い考えのように思えるかもしれませんが、実際にはこれを行わない方がはるかに良い考えです。良い解決策は、tzinfoを使用せず、UTCで時間とともにdatetimeオブジェクトを使用することです。 Python 3でバイトとUnicodeを混在させることができないように、タイムゾーンとタイムゾーンを比較することはできないという事実を考慮してください。このAPIの欠陥を独自の目的に使用してください。

プログラム内では、常にUTC時間のtzinfoなしのdatetimeオブジェクトを使用してください。
ユーザーとやり取りするときは、常にユーザーのローカルUTC時間を変換し、その逆も同様です。

datetimeオブジェクトにtzinfoを追加する必要がないのはなぜですか？第一に、大多数のライブラリはtzinfoがNoneであることを期待しているためです。 2つ目は、曲がったAPIを使用することを考えると、常にtzinfoを使用するのはひどい考えです。標準ライブラリに実装されているtzinfo変換APIはほとんどの実際のタイムゾーンで動作するほど柔軟ではないため、pytzライブラリにはタイムゾーンを変換するための代替関数があります。 tzinfoオブジェクトを使用しない場合、将来的にすべてがより良くなる可能性があります。

タイムゾーンで時間を使用しないもう1つの理由は、tzinfoオブジェクトが非常に具体的であり、その実装に大きく依存していることです。 HTTPなどを介して、タイムゾーン情報を（UTCタイムゾーンの例外を除いて）他の言語に送信する標準的な方法はありません。さらに、タイムゾーン情報を含むdatetimeオブジェクトは、pickleモジュールを使用してシリアル化すると非常に大きくなるか、シリアル化することさえできません（これはtzinfoオブジェクトの実装に依存します）。

書式設定のための変換

ユーザーのタイムゾーンで時刻を表示する必要がある場合は、UTCの時刻を持つdatetimeオブジェクトを取得し、UTCタイムゾーンを追加し、時刻をユーザーのローカル時刻に変換してフォーマットします。 tzinfoメソッドを使用したタイムゾーン変換を使用しないでください。正しく機能しないため、pytzを使用してください。次に、フォーマット用に作成した結果のdatetimeオブジェクトからタイムゾーンオフセットを破棄することにより、時間を「単純」に設定し、それ以降も幸せに生き続けます。

Dreadatourを翻訳し、テキストは％username％を読みました。

最後まで読んだ人のための翻訳者からのボーナス：

タイムゾーンに関するトムスコットのシックなビデオ：

そして、次の記事では、著者が間違っている場所、彼が間違っている理由、そして結局のところどのように正しく行われなければならないかを書きます。

「Eppur si muove！」*またはPythonでタイムゾーンを操作する