DateTimeOffset は、.Kind プロパティを UTC へのオフセットであるより便利なものに置き換えるため、DateTime と比較して、単一の時点を参照する方が適切で信頼性の高い方法であることを理解しています。
これは、単一のポイントを日時に格納することに関するすべての問題を解決しますか?それとも、懸念すべきいくつかのケースがまだありますか? (DateTimeOffset が信頼できない例があれば教えてください。)
ありがとう
DateTimeOffset は、.Kind プロパティを UTC へのオフセットであるより便利なものに置き換えるため、DateTime と比較して、単一の時点を参照する方が適切で信頼性の高い方法であることを理解しています。
これは、単一のポイントを日時に格納することに関するすべての問題を解決しますか?それとも、懸念すべきいくつかのケースがまだありますか? (DateTimeOffset が信頼できない例があれば教えてください。)
ありがとう
が与えられたDateTimeOffset
場合、それが表す時点について混乱することは決してありません。そのため、常に信頼できます。
DateTimeOffset
ただし、 aだけでは不十分な場合もあります。一般的な状況の例を次に示します。
DateTimeOffset
値は です2013-03-10T01:00:00-05:00
。2013-03-10T03:00:00-05:00
。2013-03-10T03:00:00-04:00
です。この状況を克服するには、時刻がニューヨークで記録されたことも知っておく必要があります。最初のステップでそれを知っていましたが、それを録音したときに捨てられました。アプリケーションのどこかで、この事実を保持する必要があります。できれば、正しいオフセットを再計算できるように、タイム ゾーン ID を保持することをお勧めします。
TimeZoneInfo
アプリケーションでクラスを使用する場合は、.Id
プロパティの値をDateTimeOffset
. ニューヨークの場合、タイム ゾーン ID は"Eastern Standard Time"
. DST が有効であるかどうかに関係なく、この同じ値が使用されるため、これは少し混乱します。Id
(の付いた Windows タイム ゾーンはありません"Eastern Daylight Time"
)。TimeZoneInfo
また、 aと aをペアにする組み込みのクラスまたは構造体はありませんDateTimeOffset
。あなたはそれを自分でしなければなりません。
Noda Timeを使用している場合(これを強くお勧めします)。次に、 の IANA タイム ゾーン ID と"America/New_York"
、まさにZonedDateTime
この状況向けに設計されたオブジェクトを利用できます。
DateTime vs DateTimeOffsetも参照してください。そこにあるアナロジーが非常に役立つことがわかるはずです。
適さない場合もありDateTimeOffset
ます。これは明らかなことかもしれませんが、言及する価値はあります。
これは、あなたが思っているよりも頻繁に起こります。例えば:
カレンダー上の同じ時点が同じ時点ではないという実例が他にもありますが、人々はそれらをあたかも同じ時点であるかのように考える傾向があります。
Noda Time では、LocalDateTime
これらのシナリオに a を使用します。Noda Time がなければ、 with を使用DateTime
し.Kind == Unspecified
ます。