私が知る限り、DateTime
型の差分演算子はうるう年を考慮しています:
new DateTime(2008, 3, 1) - new DateTime(2008, 2, 1) // should return 29 days
new DateTime(2009, 3, 1) - new DateTime(2009, 2, 1) // should return 28 days
しかし、サマータイムはどうでしょうか。
私が知る限り、DateTime
型の差分演算子はうるう年を考慮しています:
new DateTime(2008, 3, 1) - new DateTime(2008, 2, 1) // should return 29 days
new DateTime(2009, 3, 1) - new DateTime(2009, 2, 1) // should return 28 days
しかし、サマータイムはどうでしょうか。
.NETは、必要な答えを提供しますが、夏時間を正しく処理しません。間違った答えが欲しい。
短縮版:
.NETは、1977年にエネルギー危機のために、夏時間が1年を通して有効であったことをどのように知ることができますか?
規則がKnessetによって毎年決定される場合、.NETはどのようにしてイスラエルの夏時間規則がどうなるかを知ることができますか?
.NETは、米国が第二次世界大戦中に一年中DSTで実行され、1945年から1966年までDST規則が地域ごとに異なり、それでも規則が地域ごとに異なることをどのように知るのでしょうか。
.NETはコップアウトを試み、現在の夏時間規則が有効でなかった、または有効になる予定であっても、それらを使用します。その結果、あなたはあなたが望むと思うものであるが、間違っている答えを得ることになります。
Raymond Chenのブログエントリから、夏時間が直感的でない理由:
(win32)タイムゾーン変換関数が1年の時期に適したタイムゾーンを使用しないのはなぜですか?
..。
Win32は、その時点でどのタイムゾーンルールが有効であったかを推測しようとはしません。したがって、Win32は、「2002年10月17日木曜日午前8時45分38秒PST」と言います。
注:太平洋標準時。10月17日は太平洋 夏時間でしたが、Win32は現在の時刻であるため、標準時刻として時刻を表示します。
.NETは、「現在有効なルールが2003年10月17日に有効だった場合、それは夏時間になります」と言うので、「2003年10月17日木曜日、午前9時45分PDT」と表示されます-夏時間。
だからあなたが得る答えは間違っています。しかし、あなたは間違った答えを期待しているので、それはあなたが得るものです。
そうは思わない。ドキュメントには、DateTimeは0001年1月1日午前0時00分以降のティック数として保存されると記載されていますが、実際には午前0時がどのTimeZoneにあるかは記載されていません。常にUTCで内部的に保存され、彼らはそう言うでしょう。
ただし、これは簡単に回避できます。
var difference = Dt1.ToUniversalTime() - Dt2. ToUniversalTime()
UTCへの変換では、夏時間が考慮されます
夏時間は、一般的な 12 のタイムゾーンと、それらを使用している国よりも具体的です。
国または国のグループによって、DST が発生する日付が異なります。
それを行っていない国や一部の国のことは言うまでもなく、本当にちょっとした苦痛です。
たとえば、オーストラリアのクイーンズランド州には、国の他の地域とは異なり DST がありません。
そうでない場合でも、少なくとも cultureinfo 9 なしでは実行できません)。
UTC を使用して DateTime を作成することを強制することも、現地時間の値で DateTime を作成するときに DST が有効かどうかを指定することもできないという事実に基づいて、それは行われず、実際には CANNOTです。 . さらに、モード (LT または UTC) を「未指定」にすることができます。
現地時間の値から DateTime 値を作成できるようにすることで、あいまいな DateTime 値 (現地時間として指定) を作成することができます (たとえば、現地時間が繰り返される米国の 11 月 2 日の午前 1 時から午前 2 時までの任意の時間)。 )、確定的に UTC に戻す変換はできませんが、指定された現地時間に DST が適用されているかどうかを指定するパラメーターがコンストラクターによって提供されていない場合は除きます。
このようなパラメーターを提供しないため、DateTime クラスの設計は不完全で欠陥があり、現地時間を正しく指定するために必要なすべてのパラメーターを考慮することができませんでした。
それが、彼らが DateTimeOffset クラスを作成した理由だと思います...なぜそのような一見冗長なクラスが存在するのか混乱しているなら...それが理由です。
そのため、DateTimeMode.Utc に設定されていない DateTime インスタンスでは、いかなる種類の計算も実行しないでください。UTC のみを使用します。実際には、LT への変換も LT からの変換もできません。これは、2 つの異なるバグによって両方の方法で無効になっているためです。1. LT から UTC への移動は失敗します。これは、前述のように、LT のあいまいな 1 時間に DST が有効であったかどうかを指定できないためです。ああ、基本的に不可能なローカル時間を指定することもできます。たとえば、時計が進んでいるときにスキップする時間などです。2. 過去の UTC 値を現地時間に変換するとき、Windows は、与えられた時間ではなく、現在有効かどうかに基づいて DST をオフセットすることでそれを台無しにします。もちろん、変更時間を書き留めて保存したときに、この問題に気付いたかもしれません。またはファイル名で使用すると、ある日、Windows エクスプローラーに HOUR OFF が表示されます。Windows には重大なバグがあり、DOS のリリースと最新の .NET フレームワーク (約 20 年) の間に修正する時間がありませんでした。もちろん、そのバグは CVS システムや変更時間を追跡するあらゆるものに影響します。FAT ファイル システムは時刻をローカル タイムとして保存します。
テストして見てください!
DST の場合とうるう年の場合で行ったのと同じくらい簡単にテストを作成できます。