日付と時刻を修正する

ほとんどすべてのプロジェクトは、日付と時刻の誤った処理と保存に起因する問題に直面しています。 とにかく、同じ時間帯でプロジェクトを使用している場合でも、冬時間と夏時間に切り替えた後、不愉快な驚きを得ることができます。 同時に、最初から適切なメカニズムの実装に困惑している人はほとんどいません。これは、すべてが些細なことなので、これに問題はないと思われるからです。 残念ながら、後の現実はこれがそうではないことを示しています。



論理的には、日付と時刻に関連する次のタイプの値を区別できます。

• 日時 -「医療分析の資料は2014年1月15日13:17:15に収集されました」
• 時間のない日付 -たとえば、「2016年2月2日に新しい契約が発効します」
• 時間間隔 -「レポートは3分15秒で生成されました」
• 計画されたイベントのスケジュール -「別のシステムからのデータインポートは平日10:00に発生する必要があります」

一般的な推奨事項を忘れずに、各項目を個別に検討します。

日時

たとえば、分析のために材料を収集した研究所はタイムゾーン+2にあり、分析のタイムリーな実行が監視される中央ブランチはベルト+1にあります。 例に示されている時間は、最初の実験室で材料を収集するときに記録されました。 疑問が生じます-中央局は何時の数字を見るべきですか？ 中央オフィスのソフトウェアは、2014年1月15日12時17分15秒に表示されるべきであることは明らかです。時間に応じて、その瞬間にイベントが発生したためです。



データがクライアントからサーバーへ、またはクライアントからサーバーへ、またはクライアントからサーバーへ、またはクライアントからサーバーへデータが通過する一連の可能なアクションの1つを考えてください。

1. 値はクライアントで作成されます。たとえば、2016年3月2日15：13：36、クライアントはタイムゾーン+2にあります。
2. 値は、サーバーに送信するための文字列表現に変換されます-「2016-03-02T 15：13：36 + 02：00」。
3. シリアル化されたデータがサーバーに送信されます。
4. サーバーは時刻を日付/時刻オブジェクトにデシリアライズし、現在のタイムゾーンに戻します。 たとえば、サーバーが+1で実行されている場合、オブジェクトには2016年3月2日14：13：36が含まれます。
5. サーバーはデータをデータベースに格納しますが、タイムゾーンに関する情報は含まれません-最も一般的に使用される日付/時刻型は、単にそれについて何も知りません。 したがって、データベースは2016年3月2日14：13：36に「不明な」タイムゾーンに保存されます。
6. サーバーはデータベースからデータを読み取り、2016年3月2日14：13：36の値を持つ対応するオブジェクトを作成します。 また、サーバーは+1タイムゾーンで実行されるため、この値も同じタイムゾーン内で解釈されます。
7. 値は、クライアントへの送信用に文字列表現に変換されます-「2016-03-02T 14：13：36 + 01：00」。
8. シリアル化されたデータがクライアントに送信されます。
9. クライアントは受信した値を日付/時刻オブジェクトにデシリアライズし、現在のタイムゾーンに戻します。 たとえば、-5の場合、表示される値は2016年3月2日09：13：36になります。

すべてが全体的なように見えますが、このプロセスで何がうまくいかないかを考えてみましょう。 実際、ここでの問題はほとんどすべてのステップで発生する可能性があります。

• クライアントの時間は、タイムゾーンなしで形成できます。たとえば、DateTimeKind.Unspecifiedを指定した.NETのDateTimeタイプです。
• シリアル化エンジンは、タイムゾーンオフセットを含まない形式を使用する場合があります。
• オブジェクトにデシリアライズするとき、特に「自家製」デシリアライザー-サーバーとクライアントの両方で、タイムゾーンオフセットは無視できます。
• データベースから読み取る場合、日付/時刻オブジェクトはタイムゾーンなしで形成できます。たとえば、DateTimeKind.Unspecifiedを指定した.NETのDateTime型です。 さらに、.NETのDateTimeを使用した実際には、減算の直後に別のDateTimeKindを明示的に指定しない場合、これが実際に実際に行われます。
• 共通のデータベースで動作するアプリケーションサーバーが異なるタイムゾーンにある場合、タイムオフセットに関して深刻な混乱が生じます。 サーバーAによってデータベースに記録され、サーバーBによって読み取られる日付/時刻の値は、サーバーBによって記録され、サーバーAによって読み取られる同じ初期値とは著しく異なります。
• あるベルトから別のベルトにアプリケーションサーバーを転送すると、既に保存されている日付/時刻の値が誤って解釈されます。

しかし、上記のチェーンで最も深刻な欠陥は、サーバーのローカルタイムゾーンの使用です。 夏時間がない場合、追加の問題はありません。 しかし、そうでなければ、あなたは多くの不快な驚きを得ることができます。



夏/冬時間の変換ルールは、厳密に言えば変数です。 国によっては規則が変更される場合があり、これらの変更は事前にシステムの更新に組み込む必要があります。 実際には、このメカニズムが正しく動作しない状況が繰り返し発生しており、その結果、使用されているオペレーティングシステムまたはサードパーティライブラリの修正プログラムをインストールすることで解決しました。 同じ問題が再発する可能性はゼロではないため、それらが回避されることを保証する方法を用意することをお勧めします。



上記の考慮事項を考慮して、時間の転送と保存に対する最も信頼性の高いシンプルなアプローチを策定します。サーバーとデータベースでは、すべての値をUTCタイムゾーンにする必要があります。



この規則が私たちに与えるものを考えてください：

• サーバーにデータを送信するとき、サーバーが時刻をUTCに正しく変換できるように、クライアントはタイムゾーンオフセットを送信する必要があります。 別の方法としては、クライアントにこの変換を義務付けることですが、最初のオプションはより柔軟です。 サーバーからデータを受信すると、クライアントは日付と時刻をローカルタイムゾーンに変換します。どのような場合でも、時刻はUTCで来ることを知っています。
• UTCには夏時間の変更はないため、これに関連する問題は関係ありません。
• データベースから読み取る場合、サーバーは時間値を変換する必要はありません。UTCに対応することを明示的に示すだけで十分です。 たとえば、.NETでは、DateTimeKind.Utcの時間オブジェクトにDateTimeKindを設定することでこれを実現できます。
• 共通データベースを使用するサーバー間のタイムゾーンの違い、および1つのゾーンから別のゾーンへのサーバーの転送は、受信データの正確さに影響しません。

このルールを実装するには、次の3つのことを行うだけで十分です。

1. 日付/時刻の値がUTCからローカルタイムゾーンに、またはその逆に正しく転送されるように、シリアル化および逆シリアル化メカニズムを作成します。
2. サーバー側デシリアライザーがUTCで日付/時刻オブジェクトを作成することを確認します。
3. データベースから減算するときは、日付/時刻オブジェクトがUTCで作成されていることを確認してください。 この項目は、コードを変更せずに提供される場合があります。すべてのサーバーのシステムタイムゾーンのみがUTCに設定されます。

上記の考慮事項と推奨事項は、2つの条件を組み合わせた場合に正常に機能します。

• システム要件では、ローカル時間やタイムゾーンオフセットを保存された形式で正確に表示する必要はありません。 たとえば、航空券では、空港の場所に対応するタイムゾーンで出発時刻と到着時刻を印刷する必要があります。 または、サーバーが異なる国で作成された請求書を印刷するために送信する場合、それぞれが現地時間になり、サーバーのタイムゾーンに変換されません。
• システム内の日付と時刻の値はすべて「絶対」です。つまり、 UTCの単一の値に対応する将来または過去の時点を記述します。 たとえば、「打ち上げロケットの打ち上げは23:00キエフ時間に行われた」、または「会議はミンスク時間13:30から14:30に開催されます。」 異なるタイムゾーンでは、これらのイベントの数は異なりますが、同じ時点を表します。 ただし、場合によっては、ソフトウェア要件が「相対的な」現地時間を意味することがあります。 たとえば、「このテレビ放送は、チャンネルの支店があるすべての国で9:00から10:00に行われます。」 番組の放送は1つのイベントではなく、いくつかのイベントであり、潜在的にすべてのイベントが「絶対」スケールで異なる時間に発生する可能性があります。

最初の条件に違反した場合、サーバーとデータベースの両方でタイムゾーンを含むデータ型を使用することで問題を解決できます。 以下は、さまざまなプラットフォームとDBMSの例の小さなリストです。

.NET	DateTimeOffset
Java	org.joda.time.DateTime、java.time.ZonedDateTime
MS SQL	日時オフセット
Oracle PostgreSQL	タイムゾーン付きタイムスタンプ
MySQL	-

2番目の条件の違反は、より複雑なケースです。 この「相対」時間を単に表示するために保存する必要があり、イベントが発生した、または特定の時間帯に来る「絶対」時点を決定するタスクがない場合は、時間の変換を禁止するだけで十分です。 たとえば、ユーザーは2016年3月25日9:00にテレビ会社のすべての支店の転送の開始を入力し、このフォームで送信、保存、表示されます。 ただし、ある種のスケジューラは、各送信の開始の1時間前に特別なアクションを自動的に実行する必要がある場合があります（通知を送信するか、テレビ会社のデータベースの一部のデータの可用性を確認します）。 このようなスケジューラの信頼できる実装は、簡単なタスクではありません。 プランナーが各ブランチのタイムゾーンを認識しているとします。 そして、支社がある国の1つは、しばらくしてからタイムゾーンを変更することにしました。 ケースは見かけほど珍しいことではありません。今回と過去2年間で、このようなイベントを10個以上カウントしました（ http://www.timeanddate.com/news/time/ ）。 ユーザーはタイムゾーンバインディングを最新に保つか、スケジューラがこの情報をGoogle Maps Time Zone APIなどのグローバルソースから自動的に取得する必要があることがわかります。 私はそのような場合に普遍的な解決策を提供することを想定していません。そのような状況は真剣な研究を必要とすることに注意します。



上記からわかるように、 ケースの100％をカバーする単一のアプローチはありません 。 したがって、まず、上記の状況のどれがシステムにあるかを要件から明確に理解する必要があります。 高い確率で、すべてはUTCでのストレージを備えた最初に提案されたアプローチに限定されます。 さて、説明されている例外的な状況はそれをキャンセルするのではなく、特別な場合に他のソリューションを追加するだけです。

時間のない日付

日付と時刻を正しく表示し、クライアントのタイムゾーンを考慮して考えてみましょう。 私たちは時間のない日付に目を向け、最初にこのケースに示された例-「新しい契約は2016年2月2日に発効します。」 そのような値に対して、時間を伴う「通常の」日付と同じタイプと同じメカニズムが使用されるとどうなりますか？



すべてのプラットフォーム、言語、およびDBMSに日付のみを格納する型があるわけではありません。 たとえば、.NETにはDateTime型のみがあり、個別の「日付のみ」はありません。 そのようなオブジェクトの作成時に日付のみが指定された場合でも、時刻は存在し、00：00：00です。 値「February 2、2016 00:00:00」を+2のオフセットでベルトから変換すると、「February 1、2016 23:00:00」になります。 上記の例では、これは、ある時間帯では新しい契約が2月2日に開始され、もう1つの時間帯では2月1日に開始されることに相当します。 法的観点から見ると、これはばかげています。もちろんそうではありません。 「純粋な」日付の一般的なルールは非常に単純です。このような値は、保存および読み取りのどの段階でも変換しないでください。



日付の変換を回避する方法はいくつかあります。

• プラットフォームが時間のない日付を表す型をサポートしている場合は、それを使用する必要があります。
• この値ではタイムゾーンを無視する必要があることをシリアライザーに通知するオブジェクトのメタデータに特別な属性を追加します。
• クライアントから日付を渡し、文字列として返し、日付として保存します。 このアプローチは、クライアントが日付を表示するだけでなく、その上でいくつかの操作（比較、減算など）を実行する必要がある場合に不便です。
• 文字列として転送および保存し、クライアントの地域設定を考慮して、フォーマットのみの日付に変換します。 前のオプションよりもさらに欠点があります。たとえば、保存された文字列の日付の部分が「年、月、日」の順序でない場合、日付範囲による効果的なインデックス検索を行うことはできません。

もちろん、反例を挙げて、契約が締結された国でのみ意味があり、その国は同じタイムゾーンにあると言うことができます。したがって、有効になる時間を明確に決定することができます。 ただし、この場合でも、他のタイムゾーンのユーザーは、ローカルイベントのどの時点でこのイベントが発生するか興味がありません。 また、この時点を表示する必要がある場合でも、日付だけでなく時刻も表示する必要がありますが、これは初期条件と矛盾します。

時間間隔

時間間隔の保存と処理により、すべてがシンプルになります。その値はタイムゾーンに依存しないため、ここでは特別な推奨事項はありません。 これらは、時間単位（必要な精度に応じて整数または浮動小数点数）として保存および転送できます。 秒精度が重要な場合-何秒、ミリ秒-何ミリ秒など



ただし、間隔の計算には落とし穴があります。 2つのイベント間の時間間隔をカウントする典型的なC＃コードがあるとします。

DateTime start = DateTime.Now; //... DateTime end = DateTime.Now; double hours = (end - start).TotalHours;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一見、問題はありませんが、そうではありません。 まず、このようなコードの単体テストに問題がある可能性がありますが、これについては後ほど説明します。 第二に、最初の時間は冬時間で、最後の時間は夏時間だと想像してみましょう（たとえば、これは労働時間を測定し、労働者は夜勤を持っています）。



2016年の夏時間が3月27日の夜に発生するタイムゾーンでコードが機能すると仮定し、上記の状況をシミュレートします。

 DateTime start = DateTime.Parse("2016-03-26T20:00:15+02"); DateTime end = DateTime.Parse("2016-03-27T05:00:15+03"); double hours = (end - start).TotalHours;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは9時間になりますが、実際にはこれらの時間の間に8時間が経過しています。 これは、次のようにコードを変更することで簡単に確認できます。

 DateTime start = DateTime.Parse("2016-03-26T20:00:15+02").ToUniversalTime(); DateTime end = DateTime.Parse("2016-03-27T05:00:15+03").ToUniversalTime(); double hours = (end - start).TotalHours;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、結論- タイムゾーンに関する情報を保存するUTC値またはタイプのいずれかを使用して、日付と時刻の算術演算を実行する必要があります。 そして、必要に応じてローカルに戻ります。 この観点から、最初の例は、DateTime.NowをDateTime.UtcNowに変更することで簡単に修正できます。



このニュアンスは、特定のプラットフォームや言語に依存しません。 同様のJavaコードに同じ欠点があります。

 LocalDateTime start = LocalDateTime.now(); //... LocalDateTime end = LocalDateTime.now(); long hours = ChronoUnit.HOURS.between(start, end);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、簡単に修正されます-たとえば、LocalDateTimeの代わりにZonedDateTimeを使用します。

今後のイベントをスケジュールする

スケジュールされたイベントは、より複雑な状況です。 標準ライブラリにスケジュールを保存するためのユニバーサルタイプはありません。 しかし、このような問題はそれほどまれに発生するわけではないため、既製のソリューションを問題なく見つけることができます。 良い例はcronスケジューラ形式です。これは、Quartz： http : //quartz-scheduler.org/api/2.2.0/org/quartz/CronExpression.htmlなど、他のソリューションによって何らかの形で使用されます。 「月の第2金曜日」などのオプションを含む、スケジューリングのほぼすべてのニーズをカバーします。



ほとんどの場合、独自のスケジューラーを作成することは意味がありません。柔軟性のある時間テスト済みのソリューションがありますが、何らかの理由で独自のメカニズムを作成する必要がある場合、少なくともcronからスケジュール形式を借用できます。

一般的な推奨事項

さまざまな種類の時間値の保存と処理に関する上記の推奨事項に加えて、他にもいくつか言及したいことがあります。



まず、現在の時刻を取得するための静的クラスメンバーの使用について-DateTime.UtcNow、ZonedDateTime.now（）など。 既に述べたように、コードで直接使用すると、特別なモックフレームワークがないと現在の時刻を変更できないため、単体テストが大幅に複雑になる可能性があります。 したがって、単体テストを作成する場合は、そのようなメソッドの実装を置き換えることができることを確認する必要があります。 この問題を解決するには、少なくとも2つの方法があります。

• 現在の時刻を返す単一のメソッドでIDateTimeProviderインターフェイスを強調表示します。 次に、現在の時刻を取得する必要があるすべてのコード単位で、このインターフェイスに依存関係を追加します。 プログラムの通常の実行中に、デフォルトの実装がこれらすべての場所に注入され、実際の現在時刻が返され、単体テストでは他の必要な実装が返されます。 この方法は、テストに関して最も柔軟性があります。
• メソッドを使用して独自の静的クラスを作成し、現在の時刻と、このメソッドの実装を外部から設定する機能を取得します。 たとえば、C＃コードの場合、このクラスはUtcNowプロパティとSetImplementation（Func <DateTime> impl）メソッドを公開できます。 現在の時刻を取得するために静的プロパティまたはメソッドを使用すると、どこでも追加のインターフェイスへの依存関係を明示的に登録する必要がなくなりますが、OOP原則の観点からは、これは理想的なソリューションではありません。 ただし、何らかの理由で前のオプションが適切でない場合は、これを使用できます。

現在のタイムプロバイダーの実装に切り替えるときに解決すべき追加の問題は、「古い方法で」だれも標準クラスを使用し続けないようにすることです。 この問題は、ほとんどのコード品質管理システムで簡単に解決できます。 要するに、「デフォルト」の実装が宣言されている場合を除き、すべてのファイルで「不要な」部分文字列を見つけることになります。



現在の時刻を取得する際の2番目のニュアンスは、クライアントを信頼できないことです 。 ユーザーのコンピューターの現在の時刻は実際のコンピューターの時刻とは大きく異なる可能性があり、それに関連付けられたロジックがある場合、この違いがすべてを台無しにする可能性があります。 現在の時刻を受信する必要があるすべての場所は、可能であれば、サーバー側で実行する必要があります。 また、前述のように、時間を伴うすべての算術演算は、UTC値で実行するか、タイムゾーンオフセットを格納する型を使用して実行する必要があります。



そしてもう1つ言及したいのは、情報交換のための日付と時刻の形式を記述するISO 8601標準です。 特に、潜在的な互換性の問題を防ぐために、シリアル化で使用される日付と時刻の文字列表現はこの標準に準拠する必要があります。 実際には、書式設定を自分で実装することは非常にまれなので、標準自体は主に教育目的で役立ちます。