この記事では、プログラマーがタイムゾーンで作業するのを待つ問題について説明します。 理論的には、すべてが素晴らしく、シンプルで明確なように見えますが、人生は複雑なものであり、実際には、時には完全に予期しない状況が発生します。



TL; DR：タイムゾーンの操作は痛みと屈辱です。 タイムゾーンを使用しないでください！



そのため、 周りの人 は 、ユーザーから時間を取得したら、すぐにUTCに転送する必要があり、時間をUTCで処理するだけで、時間を厳密にUTCで保存する必要があることを伝えます。 アドバイスは一見合理的であり、それに従うことで生活が楽になります...プログラムに日付の複雑な作業が含まれていない限り。 サイトのユーザー登録の日付と時刻をデータベースに記録しますか？ オンラインストアにメッセージの送信時間または注文作成日を保存しますか？ 日時を示すメッセージをログに表示しますか？ UTCを使用すると、すべて正常になります。この記事をさらに読むことはできません。 現在の時刻はすべてUTCに完全に変換でき、問題を忘れることができます。 しかし、将来、時間とともに働きたいとしたらどうでしょうか？ または過去に？ たとえば、カレンダーサービス、またはメッセージの遅延送信サービスを作成する場合はどうでしょうか？

UTCは万能薬ではありません

例で説明します。 同じ保留中のメッセージサービスを作成したとします。 私たちのサイトを訪れたユーザーは、メールまたはSMSでいつでも（もちろん、将来的に）自分のリマインダーを作成できます。 私たちのサイトは非常にシンプルです：日付、時刻を設定し、リマインダーテキストと通信チャネル（電子メールアドレスまたは電話番号）を入力し、ユーザーから受信したデータをデータベースに入れてから、定期的に選択してメッセージを送信します。 感謝する人々のすべて、利益と敬意！



いいえ、すべてではありません。 すべての場所を常にUTCで保存するというアドバイスに従って、ユーザーから受け取った日付と時刻をUTCに変換し、データベースに格納しました。 2014年3月2日にモスクワのユーザーがサイトにアクセスし、2014年11月3日の午前9時にリマインダーを作成できるようにします。 したがって、2014年3月2日の2014年11月3日のヨーロッパ/モスクワタイムゾーンのオフセットは「UTC + 4」であったため、データベースに値「2014-11-03 05:00:00」を設定しました。



私が得ているものを参照してください？



はい、2014年7月21日、ロシア連邦下院は夏時間を廃止する法案を採択しました。 この法律によると、2014年10月26日から、ヨーロッパ/モスクワのタイムゾーンへの移行は、「UTC + 4」ではなく「UTC + 3」になりました（夏時間も取り消されましたが、現在はそうではありません）。 したがって、ユーザーに11月3日午前5時にUTCに通知を送信すると、ユーザーはモスクワの午前8時にその通知を受け取ります。



結論は簡単です。時間をUTCで保存できますが、現在および最近の過去のイベント、つまり、タイムゾーンが変更されない日付のイベントのみを保存できます。 将来の日付にUTCで時間を保存するのは危険です。なぜなら、どの国の政府が他の法律を採用し、10年、5年、さらには1年でタイムゾーンに何が起こるかわからないからです。



一方、ユーザーのローカル時間とユーザーのタイムゾーンをデータベースに保存すると、そのようなデータを操作することは事実上不可能になります。 通知サービスの例に戻ります：通知によって作成された2人のユーザー。 モスクワの最初のユーザーは、2014年12月15日15:00にSMSを送信するように要求しました（データベースにローカル時間「2014-12-15 15:00:00」とタイムゾーン「ヨーロッパ/モスクワ」を書き込みます）。 ニューヨークの2番目のユーザーは、2015年12月15日午後7時に電子メールを送信するように要求しました（データベースに彼の現地時間「2014-12-15 19:00:00」とタイムゾーン「America / New_York」を記述します） ） これまでのところ、ユーザーが通知を受け取りたい現地時間を記録しており、これらの国の政府がこれらのタイムゾーン（オフセット、夏時間、何でも）。



送信するデータベースから通知を選択するスクリプトを作成すると、問題が始まります。 すべての日付がUTCで記録されている場合、すべてが単純になります-送信するメッセージを毎分選択します。

SELECT * FROM reminders WHERE remind_time < NOW();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「SELECT NOW（）;」は、UTCで時刻を返します。 しかし、ユーザーの現地時間とユーザーのタイムゾーンをデータベースに記録しました。どうすればよいでしょうか。 苦しむ:-)結局のところ、UTCによる「NOW（）」はモスクワでは「+3」時間（メッセージはすでに遅れています）、ニューヨークでは「-5」時間（メッセージを送信するには早すぎます）です。



いいえ、もちろん、データベースから送信する通知を選択する多くの方法を考えることができますが、多かれ少なかれ負荷のかかったサービスでそれらすべてがパフォーマンスの問題につながります。



オプションは何ですか？ それらの多くがありますが、データベースに3つの値を保存するために、多かれ少なかれ受け入れられるオプションが1つしかありません：UTCの時間（このフィールドによるサンプリング用）、ユーザーの現地時間、およびタイムゾーン（タイムゾーン）。 はい、冗長なデータを保存しますが、データの非正規化に頼らない単一のロードされたサービスは知りません。 現実の世界では、これは正常です。 得られる利点は何ですか？ タイムゾーンが変更された場合、特別なスクリプトを使用して変更されたタイムゾーンのエントリを調べ、タイムゾーンの更新の結果として変更された場合はUTCで時刻を更新できます。 私の謙虚な意見では、これは良い妥協案です。

思ったよりもさらに悪い

すべてのように、ハァッ？ いいえ、始めたばかりです:-)政府はタイムゾーンの構成を変更できるだけでなく、新しいタイムゾーンを追加して古いタイムゾーンを破棄することもできます。 そのため、たとえば、ロシアの都市チタの居住者（およびそれだけではなく、現在ではない）については、2014年10月26日に、「タイムゾーンが存在しない前に」新しいタイムゾーン「アジア/チタ」が導入されましたアジア/ヤクーツク」。 前のタイムゾーン（「アジア/ヤクーツク」）のUTCとの差は「+09：00」であり、新しいタイムゾーン（「アジア/チタ」）ではこの差は「+08：00」です。 問題は、データベースにユーザーの時間とタイムゾーンのみを保存し、地理的な場所は保存しないことです。 また、「アジア/ヤクーツク」タイムゾーンのエントリの場合、ユーザーが知多かヤクーツクのどちらであるかを知ることはできず、メッセージがユーザーに送信された時刻を確実に判断することはできません。 チェックしてチェックメイト！ 友人を苦しめることを忘れないでください。



ユーザーの地理的位置を確認する機会があり、ユーザーが次にサイトにアクセスしたときに、ユーザーがタイムゾーンが変更された地域（上記の場合はChita）にいると判断した場合、ユーザーに正しいタイムゾーンを尋ねることができます。 また、すべてのイベントのタイムゾーンを更新すること（各イベントのUTCでの時間の再計算）を提案することもできますが、この記事の範囲を超える落とし穴とニュアンスもここで発生する可能性があります。 ちなみに、一部にはこの理由で、 mail.ruカレンダー設定で、他のサービスが行うように、タイムゾーンではなく地理的な場所（都市）を選択するようにユーザーに求めます:-)それでも、時々問題があると正直に言います。



過去の時間を保存することも簡単ではありません。 この過去が比較的最近の場合（たとえば、21世紀について話している場合）、UTCでの時間の保存に問題はないはずです（もちろん、だれも保証しません）。 20世紀または（ああ、ホラー）より古い時代について話している場合、問題は保証されます。 そもそも、前世紀の歴史の多くの期間において、時計の翻訳に関する情報は今日に至るまで絶えず変化しています。 そのため、たとえば、2014年8月30日付のタイムゾーンデータベースtzdataバージョン2014gの更新では、ソ連の多くのタイムゾーンで、1926年までの日付に対して数秒または数分変更が加えられました。 誰かが矛盾に気づき、これについてtzdataコンパイラーに通知しました。 または、近い時期の別の例を次に示します。2014年3月9日の更新tzdataバージョン2014aでは、ウクライナのモスクワ時間から東ヨーロッパ時間への移行日に関する情報が変更されました。この移行は1992年1月1日に発生しませんでしたが、 1990年7月1日



タイムゾーンのデータベースは年に数回更新され、新しいタイムゾーンが世界中に表示され、既存のタイムゾーンのルールが変更され、過去の時間に関する情報が更新され、一部の変更が常に発生するため、それらを常に考慮する必要があります。

それでは、どのように時間を正しく保つのですか？

では、どのようにしてデータベースに時間を正しく保存することができますか？ もちろん、これを行わない方が良いですが、本当に必要な場合は、個人的な推奨事項があります（批判や提案を聞いてうれしいです）：

1. 発生したイベントの時刻、特定のアクションの後の現在時刻を保存する必要がある場合は、UTCで保存します。 これらは、ログエントリ、ユーザー登録の時間、手紙の注文または送信です。
2. 時刻がユーザーまたはユーザーのタイムゾーンに関連付けられていない場合は、UTCで保存します。 これは、たとえば、次の日食の時間かもしれません。
3. 過去または未来の時間を保存する必要がある場合は、ユーザーの現地時間を保存し、タイムゾーンを近くに保存します。 そしてさらに良いので、確かに、ユーザーの地理的な位置を保持します。 この時間のサンプルを作成する必要がある場合は、時間を近くのUTCで保存し、タイムゾーン情報を変更するときにこの時間を更新します。
4. 特定の地理的位置の任意の日付の時刻を正確に知る必要がある場合（たとえば、天文計算の場合）-ユーザーのタイムゾーンではなく、ユーザーの正確な座標を保存します。 ただし、そのようなタスクに直面している場合は、正しい方法をすでに知っています。

最初のオプションは、プログラムの99％の可能なユースケースをカバーしており、おそらく、これで十分です。 ただし、アクションの1つまたは別のバージョンの選択を明確に理解し、認識する必要があります。

時間とともに働く

時間の保存、並べ替え、整理。 ただし、「常にUTCの時間で動作する」というアドバイスを聞くことができます。 ユーザーから時間を受け取るとすぐに、それをすぐにUTCに転送し、UTCの時間でのみ動作する必要があることが理解されています。 論理的に聞こえますか？



違います。 少なくともすべての場合ではなく、ここに具体的な例を示します。



遅延メッセージのサービスを使用して例に戻りましょう。 すべては順調で、サービスは開発中です。ユーザーは満足していますが、繰り返し通知の機能を追加するよう求めています。 また、繰り返しは単純（「毎日」、「隔日」、「毎月」）だけでなく、非常に複雑です（「毎週火曜日の週」、「毎月最後の金曜日の毎月」など）。 これらの繰り返しのために自転車を書かないために、既製のソリューションを研究します。 「定期的なイベント」などがあります。 繰り返しの規則を記述するための特別な形式があります。もちろん、すべての可能なオプションを考慮していません（たとえば、「2 in 2」を指定することはできません）が、ほとんどの場合をカバーします。 この形式のアプリケーションの例は、 iCalendar仕様の RRULEフィールドの説明と 、Pythonのpython-dateutilモジュールのrruleオブジェクトのドキュメントで見ることができます。



python-dateutilモジュールをコードで使用します。 すべてがうまくいくように見えますが、ユーザーは文句を言います、そして、これらの不満の研究はかなり予期しない結果で私たちを導きます。



定期的なイベントの1つのオプションは、曜日ごとに繰り返すことです。 たとえば、毎週火曜日と金曜日の12:00に繰り返されるイベントを記述できます。 実際のコードで実際にどのように見えるかを次に示します。

 >>> import datetime >>> from dateutil import rrule >>> list(rrule.rrule(rrule.WEEKLY, count=4, byweekday=(rrule.TU, rrule.FR), dtstart=datetime.datetime(2014, 11, 3, 12, 0))) [datetime.datetime(2014, 11, 4, 12, 0), datetime.datetime(2014, 11, 7, 12, 0), datetime.datetime(2014, 11, 11, 12, 0), datetime.datetime(2014, 11, 14, 12, 0)]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが順調に進んでいるようです。 ここで、モスクワのユーザーが朝の1時に発生する定期的なイベントを作成したとします。 彼から「2014-11-03 01:00:00」という時間を得るとすぐに、私たちは賢い人の推奨に従って、すぐにそれをUTCに転送します（今は翻訳プロセスに興味がありません。実際には3時間かかることを知っておく必要があります）受信した時間から）、UTCの次の時間を取得します：datetime.datetime（2014、11、2、23、0）。 これまでのところ良い。 受信した時間のリプレイを取得しましょう：

 >>> list(rrule.rrule(rrule.WEEKLY, count=4, byweekday=(rrule.TU, rrule.FR), dtstart=datetime.datetime(2014, 11, 2, 23, 0))) [datetime.datetime(2014, 11, 4, 23, 0), datetime.datetime(2014, 11, 7, 23, 0), datetime.datetime(2014, 11, 11, 23, 0), datetime.datetime(2014, 11, 14, 23, 0)]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何かが間違っているようです。 取得した値をユーザーの現地時間に変換すると（それぞれに3時間追加されます）、繰り返しが移動し、イベントは午前1時ですが、水曜日と土曜日にすべて同じように繰り返されることがわかります。 これはpython-dateutilモジュールのエラーではなく、コードは正しく機能しました。 これは私たちの間違いです。この特定のケースでは、ユーザーの現地時間で作業する必要がありました。



ところで、多くのカレンダーサービスにはこのバグがあります。たとえば、OS XのiCalプログラムは、特定の場合、再試行が完全に間違っていると見なします。

苦しむことを忘れないでください

結論は簡単で完全に平凡にすることができます。これらのことは絶対にしないことを推奨するカテゴリーの声明を聞かないでください。 特に、プロジェクトアーキテクチャを慎重に研究し、品質テストを作成し、それらを最新の状態に保ちます。



そして、タイムゾーンでの作業は苦痛と苦痛です。 彼らと仕事をしないわずかな機会さえあれば-それを使用して、あなたはそれを後悔しないでしょう。 最後に、実際のプログラムの不正な操作の例をいくつか示します。



Python 2.7.6

 ➜ date , 9  2014 . 22:44:32 (MSK) ➜ python -c "import datetime; print datetime.datetime.now()" 2014-11-09 22:44:33.310904 ➜ python -c "import datetime; print datetime.datetime.utcnow()" 2014-11-09 19:44:34.405287
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてがうまくいくようです。 さらに調査します。

 ➜ date +%z +0300 ➜ python -c "import time; print time.timezone/3600" -4
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ワット？ いいえ、これはバグではなく機能ですが 、誰にとっても簡単ではありません。 いつでも壊れる可能性がある（そして壊れる）コードのポイントは何ですか？



Firefox 33.0.3

 new Date(2015, 0, 6) "Tue Jan 06 2015 00:00:00 GMT+0300 (Russia TZ 2 Standard Time)" new Date(2015, 0, 7) "Tue Jan 06 2015 23:00:00 GMT+0300 (Russia TZ 2 Standard Time)" new Date(2015, 0, 8) "Thu Jan 08 2015 00:00:00 GMT+0400 (Russia TZ 2 Daylight Time)"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ワット？ いいえ、私はこの問題が何度も提起されていることを理解していますが、これから生きることは容易ではありません。



一般的に、私が言うことができる、 苦しむことを忘れないでください :-)



日付、時間、タイムゾーンをどのように使いますか？



ウラジミール・ルドニク、

Mail.Ruカレンダーのテクニカルディレクター