では、DateTime構造の何が問題になっていますか？

備考：

1. 前の 記事 「タイムゾーン」では、特定の名前を持つ米国のタイムゾーンの問題であったため、 「 タイムゾーン 」と翻訳しました。 この場合、「 タイムゾーン 」を使用する方がより正確です。 ここでは、より正確な翻訳が使用されます。



2.ウィキペディアの小さなサイドバーでは、UTCとは何か、GMTとの違いについてのアイデアが表示されます-



協定世界時 （UTC）は、社会が時間と時間を規制する基準です。 原子時間から整数の秒数と、世界標準時UT1からの秒の小数部が異なります。



廃止されたグリニッジ標準時（GMT）の代わりにUTCが導入されました。 GMTスケールは不均等なスケールであり、地球の毎日の回転に関連しているため、新しいUTCタイムラインが導入されました。 UTCスケールは、統一された原子時間スケール（TAI）に基づいており、民間での使用により便利です。



世界中のタイムゾーンは、UTCからの正および負のオフセットとして表されます。



UTC時間は冬でも夏でも変換されないことに注意してください。 したがって、夏時間への切り替えがある場所では、UTCに対するオフセットが変更されます。





現在は、日付や時刻などのエンティティにサービスを提供する構造を引き続き扱います。



野田タイムについてのツイートを投稿してしばらくして、 野田タイムを使うことのポイントは何なのかと聞かれ始めました。 もちろん、私は彼らのコードを見ませんでしたが、日付を処理するほとんどすべてのコードベースが野田時間を使用するとより明確になり、また、おそらく、野田時間があなたに受け入れることを強制するアプローチのためにより正確になるでしょう.NETでは明らかではないいくつかのソリューション。 この記事では、日付と時刻を操作するための.NET APIの欠点について説明します。 このトピックに対する私の態度はやや偏っているように見えますが、この記事がBCL（Base Class Library- およそTranslator ）に取り組んでいるチームに無礼に見えないことを願っています。 COMなどとの相互作用を考慮に入れる



DateTimeの意味？



StackOverflow Webサイトで、DateTimeが期待どおりの動作をしていないという質問に出くわすと、多くの場合、リフレクションの状態になります。 答えは簡単です。日付と時刻ですよね？ しかし、問題をより慎重に処理し始めるとすぐに、すべてがより複雑になります。 たとえば、次のコードの2つのプロパティの呼び出し間でクロックが刻まなかったとします。 それでは、ミステリー変数はどのような値を取るのでしょうか？



DateTime utc = DateTime.UtcNow;<br>DateTime local = DateTime.Now;<br>bool mystery = local == utc;







正直なところ、このコードの実行が何につながるかわかりません。 3つのバージョンがあり、それぞれに多少の正当化があります。

• 値は常に真になります 。2つの値は同じ瞬間に関連付けられ、1つだけがローカルに表現され、2番目の値は普遍的です。
• 値は常にfalseになります 。2つの値は2つの異なる日付値を表します。 自動的に等しくない
• 繰り返しますが、ローカルタイムゾーンがUTC（ 協定世界時 ）と同期している場合、つまり タイムゾーンがまったく考慮されていない場合-両方の値が等しくなります

どの答えが正しいかはあまり気にしません-コードの動作のロジックの非自明性は、より深い問題の兆候です。 実際、すべてがDateTime.Kindプロパティに戻ります。これにより、DateTimeは3種類の値を表すことができます。



DateTimeKind.Utc ：UTCの日付と時刻

DateTimeKind.Local ：コードが実行されるシステムのローカルな日付と時刻

DateTimeKind.Unspecified ：うーん、ずるい。 あなたがそれで何をするかに依存します。



プロパティの値は、操作ごとに異なる効果を持ちます。 たとえば、ToUniversalTime（）メソッドを「指定されていない」DateTime値に適用すると、メソッドはローカル値を変換しようとしていると仮定します。 一方、ToLocalTime（）メソッドを「指定されていない」DateTime値に適用すると、UTCの値が最初にあったと想定されます。 これは、動作の1つのモデルです。



DateTimeとTimeSpanからDateTimeOffsetを作成する場合、動作はわずかに異なります。

• UTC値ではすべてが単純です-UTCを転送し、「UTC +指定されたオフセット」表現を受け取りたい
• ローカル値はときどきtrueになります：コンストラクターは、デフォルトでシステムが使用するタイムゾーンで指定されたローカル時間のUTCからのオフセットが、ユーザーが指定したオフセットでチェックします
• 未指定の値（「未指定」）は常にtrueであり、特定のタイムゾーンの現地時間を表しているため、その時点でのオフセットは正確です。

私はあなたのことは知りませんが、私にとってこの状況はわずかなセマンティックなヒステリーを引き起こします。 数字のシーケンスを含む「数値」タイプを持つのと同じですが、10進数または16進数を見つけるために別のプロパティを使用する必要があり、答えは「さて、どう思いますか？」です。



もちろん、.NET 1.1では、DateTimeKindプロパティは完全に存在していませんでした。 これは、問題が存在しなかったという意味ではありません。 これは、異なる種類の値を格納し、一貫性を保とうとしないタイプに意味を与えようとする混乱した動作を意味します。 これは、日付値が永続的に未指定であるという仮定に基づいていました。



DateTimeOffset構造を使用すると問題は解決しますか？



いいね これで、DateTime型があまり好きではないことがわかりました。 DateTimeOffsetは役立ちますか？ はい、一部。 DateTimeOffset型の値には明確な意味があります。UTCからのオフセットを指定したローカルの日付と時刻が含まれています。 おそらく今、私は「一時的な」瞬間と同様に「現地」の日付と時刻が意味することを後退させ、あなたに説明しなければなりません。



ローカルの日付と時刻は、特定のタイムゾーンに関連付けられていません。 現在は「2012年3月13日16:00」以降ですか？ あなたがこの世界のどこにいるかに依存します（ちなみに、私はまだISO以外のカレンダーを考慮していません）。 したがって、DateTimeOffsetには、タイムゾーンに依存しないコンポーネント（これは「16:00 ...」）が含まれますが、UTCからのオフセットも含まれます。これは、タイムラインのある時点での変換の可能性を示します。 相対性理論を無視すると、地球上のすべての人々が同時に現在の瞬間を知覚します。 指をスナップすると（無限に高速）、このイベントの前または後に宇宙のイベントが発生します。 特定のタイムゾーンにいたかどうかは関係ありません。 この点で、各個人が特定の瞬間に観測できる現地の日時と比較して、瞬間はグローバルです。



（まだここにいますか？続けましょう-前の段落がこの記事で最も難しかったことを願っています。非常に重要な概念を説明していますが。）



したがって、DateTimeOffsetは（グローバルな）特定の時点を指しますが、ローカルの日付と時刻でも機能します。 つまり、この構造はローカルの日付と時刻を表すのに理想的なタイプではありませんが、DateTimeはそうではありません。 DateTimeKind.Localプロパティが設定されたDateTimeは、同じ理由で実際にはローカルではありません-使用されるシステムのデフォルトのタイムゾーンに関連付けられています。 DateTimeKind.Unspecified形式のDateTimeは、場合によっては少し優れています-たとえば、DateTimeOffsetを作成する場合-しかし、上記のように、セマンティクスは他の場合では奇妙に見えます。 その結果、DateTimeOffsetもDateTimeも、真にローカルな日付と時刻を表示するのに適したタイプではありません。



DateTimeOffset構造は、どのタイムゾーンが対応するオフセットを最初に与えたかわからないため、特定のタイムゾーンへのバインドには適していません。 .NET 3.5には、適切なTimeZoneInfoクラスがありますが、「特定のタイムゾーンの現地時間」というタイプはありません。 したがって、DateTimeOffset型の変数を使用すると、特定のタイムゾーンの特定の時刻はわかりますが、この時刻のオフセットが変更される可能性があるため（通常は夏時間のため）、現地時間は1分後になります。



日付と時間はどうですか？



これに先立ち、「日付と時刻」を格納する値のみを説明しました。 また、日付のみまたは時刻のみが格納されるタイプについてはどうでしょうか？ 多くの場合、もちろん、日付のみを保存する必要がありますが、時間のみを保存する必要がある場合があります。



さらに、はい、DateTime型を使用して日付を保存できます。特定の日付と時刻の日付を返すDateTime.Dateプロパティもありますが、真夜中に時刻が設定された別のDateTime値としてのみです。 これは、「日付のみ」（または「時間のみ」-.NETがこれを行うためにTimeSpanを使用しているため、簡単に識別できる別のタイプを持つこととは異なります。



そして、タイムゾーンはどうですか？ ここでは、TimeZoneInfoはかなり適切に見えます。



先ほど言ったように、TimeZoneInfoは悪くありません。 確かに、彼には2つの大きな問題といくつかの小さな問題があります。



まず、Windowsタイムゾーン識別子が基礎として使用されます。 一方では論理的ですが、他方では、世界の他の人々が使用するものではありません。 私が見たすべての非Windowsシステムは、それぞれOlsonタイムゾーンデータベース（tzまたはzoneinfoとも呼ばれます）を使用し、独自の識別子を持っています。 「ヨーロッパ/ロンドン」または「アメリカ/ Los_Angeles」など、それらを見たかもしれません-これらはオルソンの識別子です。 地理情報を提供するWebサービスを使用します。Olson識別子を使用する可能性があります。 別のカレンダーシステムを使用します。Olson識別子も使用する可能性があります。 ここにも問題があります。 たとえば、 Unicodeコンソーシアムが CLDRを使用して解決しようとしている識別子の安定性を備えていますが、少なくともあなたにはチャンスがあります。 TimeZoneInfoが2つの識別子スキーム間の通信を確立する何らかの方法を提供するか、または.NETの別の場所で実装されるのは素晴らしいことです。 （Noda Timeは両方の識別子のセットを知っていますが、マッピングはまだ誰もが利用できるわけではありません。最終リリースの前に修正されます。）



第二に、このクラスはDateTimeとDateTimeOffsetの使用に基づいています。 使用する場合は注意が必要です。あるタイプのDateTimeを設定して別のタイプを渡すと、問題が発生する可能性があります。 クラスはかなりよく文書化されていますが、正直なところ、この種のことを説明することは、矛盾する用語を使用して状況を混乱させずに本質的に非常に困難です。



ローカルの日付と時刻の値があいまいまたは誤っているという問題があります。 これらは夏時間/冬時間への移行中に発生します：時間を進めると（たとえば、1：00から2:00まで）、間違った現地時間を取得する可能性があります（たとえば、その日の1:30は来ません）。 クロックを遅らせると（たとえば、2：00から1:00まで）、これによりあいまいさが生じます。1.30は2回発生します。 特定の値が正しくない、またはあいまいな場合は、TimeZoneInfoを使用して明示的に確認できますが、そのような可能性については簡単に忘れてしまいます。 UTCでタイムゾーンを使用してローカル時間を変換しようとすると、時間が正しくない場合に例外がスローされます。 ただし、あいまいな時間は標準のデフォルトとして使用されます（夏時間ではありません）。 この種のソリューションでは、開発者が使用されている機能を考慮することさえできません。 どのことについて話す...



複雑すぎる



今、あなたは非常によく考えるかもしれません：「私はハエから象を吹き飛ばしました。 私はそれについて考えたくない-なぜあなたは物事をそんなに複雑にしようとしているのですか？ 私は何年も.NET APIを使用してきましたが、問題は発生していません。」 もしそうなら、私は3つのオプションを提供できます：

• あなたは私よりもはるかに賢く、直感的なレベルでこれらの困難をすべて理解しています。 DateTime型の変数には常に正しいビューを使用します。 必要な場合-DateTimeOffsetを使用し、常に間違ったまたはあいまいなローカル日付/時刻で正しいことを行います。 間違いなく、オブジェクトの状態への共有アクセスを備えたノンブロッキングマルチスレッドコードを最も効率的かつ信頼性の高い方法で記述します。 一体何を読んでるの？
• あなたはこれらの問題に遭遇しましたが、大部分はそれらを忘れていました-最後に、許容できる結果を得るために実験している間（または少なくともテストに合格するために、そのようなテストは概念的に正しくないかもしれませんが）あなたの人生のたった10分しかかかりませんでした。 この問題に戸惑っていたかもしれませんが、問題はAPIではなくあなたにあると判断しました。
• 夜間に常にオフになっている（つまり、冬/夏の移行の影響を受けない）コンピューター上で同じタイムゾーンで動作するため、退屈なタスクのコードテストを検討するため、この問題は発生しませんでした。 あなたはある程度幸運ですが、それでもあなたはタイムゾーンを忘れます。

冗談はありませんが、問題は本当に現実的です。 そして、この記事の前に「ローカル」時間と「グローバル」時間の違いについて考えたことがないなら、あなたはそれをやった。 これは重要な違いです。2進浮動小数点数と10進浮動小数点数の違いに似ています。 エラーは明らかではなく、診断が難しく、説明が不十分で、修正が不十分で、プログラムの他の場所で再発する場合があります。



日付/時刻を格納する変数の値を処理するのは本当に簡単ではありません。 夏/冬時間への移行により、深夜に始まらない日などの不快なケースがあります（たとえば、2010年10月17日日曜日、ブラジルでは1:00に始まりました）。 特に不運な場合は、マルチカレンダーシステム（グレゴリオ、ジュリアン、コプト、仏教など）で作業する必要があります。 20世紀初頭の日付と時刻を扱っている場合は、厳密に経度の偏りがより「丸められた」値にシフトするため、タイムゾーンの非常に奇妙な移行に気づくでしょう（たとえば、1911年のパリ）。 実際のシフトの数週間前に、タイムゾーンを変更する政府がこれについての警告とともに出会うことがあります。 また、タイムゾーン識別子の変更が発生する場合があります（たとえば、アジア/カルカッタからアジア/コルカタ）。



もちろん、これはすべて、実装しようとしている関連するビジネスルールの表面にあります。 そして、彼らも難しいことができます。 これらのすべての複雑さを考えると、少なくともあなたが意味することを比較的明確に表現できるAPIが必要です。



野田タイムは完璧ですか？



もちろん違います。 野田タイムにはいくつかの問題があります。

1.上記のすべてにもかかわらず、私は日付と時刻の理論に関してはアマチュアです。 調整の2番目は私を混乱させます。 ユリウス暦のグレゴリオ暦への変更点を考えると、泣きたいという欲求が私を覆い、したがって、私はまだ気づいていません。 私の知る限り、Joda Timeの作者でJSR-310の責任者であるStephen Colebourneはメーリングリストに潜んでいますが、Noda Timeプロジェクトの参加者は1人も専門家ではありません。 （ちなみに、彼は最初の野田タイムプレゼンテーションに参加しました。部屋の誰かがグレゴリオ暦とISO-8601標準カレンダーの違いを知っているかどうか尋ねました。彼は手を挙げて正しい答えをしました。そして彼は答えた：「私はスティーブン・コールボーンです。」私はほとんど倒れました）。

2.まだ完了していません。 実装がなければ、優れたAPI設計は役に立ちません。

3.間違いなくエラーが発生します。BCLコマンドコードは世界中の何十万台ものマシンで常に実行されています。 エラーはすぐに表示されます。

4.私たちにはリソースがありません-私たちは喜びで働く開発者のアクティブなグループです。 私はこれについて後悔しているわけではありません（これは本当に素晴らしいことです）が、追加のチップ、ドキュメントなどの作業に割り当てられる時間には避けられない問題があります。

5.私たちはBCLの一部ではありません。 LINQ to SQL（またはNHibernate）クエリでNoda Timeを使用したいですか？ がんばって。 期待以上に成功したとしても、何世紀にもわたって私たちに依存する他のオープンソースプロジェクトはないだろうと思います。 特定の目標を達成するための柔軟性と単純さのバランスを維持しようとしました（もちろん、より多くの努力を払って）。 どういうわけか、使用したデザインスタイルに関する別のメモを作成し、Joda Timeデザインと.NETで使用したデザインの両方と比較します。 最良の結果は、結果として得られるタイプのセットであり、各タイプには非常に明確な役割があります。 詳細については説明しません。このためのドキュメントやその他のメモがあります。



奇妙なことに、BCLに取り組んでいるチームがこの記事に注意を払い、.NET 6のAPIを根本的に再設計することを決定する方が良いでしょう（ ".NET 5"船は既に発売されていると思います）。 そして、これを行っている間、私は喜びを与える他の多くのプロジェクトがあると確信しています-率直に言って、日付と時刻の問題は.NETコミュニティにとって長い間私の肩の上にのみ存在するには重要すぎます。



結論



.NET APIに重大な欠陥があることを納得していただければ幸いです。 おそらく、私はあなたに、野田タイムがより親しい知人に値すると確信しましたが、これは主な目標ではありませんでした。組み込み型の欠点、特にDateTimeのセマンティックなあいまいさを本当に理解している場合は、コードでこれらの型を細心の注意と正確さで使用する必要があります。そして、これだけが私を幸せにします。



（まあ、この作品を最後まで読んだら、翻訳に時間を費やしたのは無駄ではなかったことを意味します-翻訳者のメモ）。



非常に無料の翻訳（c）Alien V.F. 別名hDrummer、ここにオリジナル。