DateTime（UTC）の保存とDateTimeOffsetの保存
通常、データベースとの間で読み書きを行う直前にDateTime変換（UTCから現地時間、現地時間からUTC）を行う「インターセプター」があるため、DateTime.Now（派生および比較）タイムゾーンを気にせずにシステム全体で。
シリアル化とコンピューター間でのデータの移動については、日時は常にUTCであるため、気にする必要はありません。
UTC形式で日付（SQL 2008-datetime）を保存し続けるべきですか、それともDateTimeOffset（SQL 2008-datetimeoffset）を使用して保存する必要がありますか？
データベース内のUTC日付（datetime型）は機能しており、長い間知られていますが、なぜそれを変更するのですか？利点は何ですか？
私はすでに this one のような記事を調べましたが、100％確信しているわけではありません。何かご意見は？
UTCだけを使用できないという大きな違いが1つあります。
このようなシナリオがある場合
- 1台のサーバーおよび複数のクライアント（すべて地理的に異なるタイムゾーンで）
- クライアントは日時情報を使用してデータを作成します
- クライアントはすべて中央サーバーに保存します
次に：
- datetimeoffsetはUTC時間とALSOオフセットを保存クライアントの現地時間
- すべてのクライアントは、すべてのデータのUTC時間と、情報の発信元の現地時間を知っています。
しかし：
- TC datetimeはUTC datetimeのみを保存します
- 他のクライアントは、日時情報の発信元である場所の現地時間を知りません
- 他のクライアントは、データの発信元であるクライアントのローカル時間ではなく、データベースからローカル時間のみを計算できます（UTC時間を使用）。
簡単な例は、航空券予約システムです...航空券には2回含まれる必要があります。
すべての履歴時間にUTCを使用することは絶対に正しい（つまり、イベントの記録）。 UTCから現地時間に移動することは常に可能ですが、常にその逆ではありません。
現地時間を使用する場合この質問に答えてください：
政府が突然夏時間の変更を決定した場合、このデータを一緒に変更しますか？
答えが「はい」の場合にのみ現地時間を保存します。明らかに、それは将来の日付のみであり、通常は何らかの形で人々に影響を与える日付のみです。
タイムゾーン/オフセットを保存する理由
まず、アクションを実行したユーザーのオフセットを記録する場合は、おそらくそれを行うだけでよいでしょう。つまり、ログイン時にそのユーザーの場所とタイムゾーンを記録します。
次に、表示用に変換する場合は、そのタイムゾーンのすべてのローカルタイムオフセット遷移のテーブルを用意する必要があります。現在のオフセットだけでは不十分であることがわかります。異なる。
DATETIMEOFFSETを使用すると、ローカル時間とUTC時間を1つのフィールドに保存できます。
これにより、表示用のデータを処理する必要なく、ローカル時間またはUTC時間での非常にシンプルで効率的なレポートが可能になります。
これらは、2つの最も一般的な要件です。ローカルレポートのローカル時間とグループレポートのUTC時間です。
現地時間はDATETIMEOFFSETのDATETIME部分に格納され、UTCからのOFFSETはOFFSET部分に格納されます。したがって、変換は簡単であり、データのタイムゾーンを知る必要がないため、すべてデータベースレベルで実行できます。 。
ミリ秒までの時間を必要としない場合、例えばほんの数分または数秒で、DATETIMEOFFSET（0）を使用できます。 DATETIMEOFFSETフィールドは、8バイトのストレージのみを必要とします-DATETIMEと同じです。
したがって、UTC DATETIMEではなくDATETIMEOFFSETを使用すると、レポート作成の柔軟性、効率性、およびシンプルさが向上します。