日時データの亡霊：VB.NETにおける`DateTime`と`DateTimeOffset`の非妥協的使い分け
レガシーなVBAシステムから移行したエンジニアや、デスクトップアプリの温室育ちのままクラウド時代に突入した開発者が、必ず踏み抜く地雷がある。それが「日時（DateTime）」の扱いだ。
「とりあえず `DateTime.Now` を使っておけば動く」
「データベースには `DATETIME` 型で保存しているから問題ない」
そんな甘い認識は、グローバル展開、サマータイム（DST）の導入、あるいはクラウドサーバーのリージョン変更（UTC運用）によって一瞬で粉砕される。特に、VB.NETで堅牢な基幹システムを構築するシニアエンジニアにとって、時刻の曖昧さはシステムの信頼性を失墜させる最大の癌（がん）である。
今回は、VB.NETにおける `DateTime` と `DateTimeOffset` の根本的な差異を暴き、タイムゾーンの罠を完全回避するための極限の知見を授ける。
—
1. 構造的欠陥：なぜ `DateTime` だけでは世界を渡れないのか
多くのVB.NETプログラマが愛用してきた `System.DateTime`。だが、こいつの本質は「タイムゾーンを持たない、ただの瞬間（あるいは壁時計の時刻）」である。
`DateTime` の内部構造は、西元0年からのティック数と、`DateTimeKind`（`Utc`, `Local`, `Unspecified`）という極めて脆弱なフラグで構成されている。
.net
‘ 危険なDateTimeの初期化例
Dim dtLocal As DateTime = DateTime.Now
Dim dtUtc As DateTime = DateTime.UtcNow
‘ 問題: Kindが異なっていても、値の比較や演算が暗黙的に行われ、バグの温床となる
`DateTimeKind.Unspecified` の呪い
レガシーシステムや外部API連携、あるいはCSVインポートにおいて最も恐ろしいのが `Unspecified`（未指定）だ。これは「今何時か分からないが、とにかく10時だ」という暴挙を許す。この `DateTime` をそのまま異なるタイムゾーンのサーバーへ渡したり、DBに突いたりした瞬間、時刻は音もなくズレ始める。
API仕様書に「ISO 8601形式で送信せよ」とある場合、`DateTime` をそのままシリアライズすると、タイムゾーンオフセット（`+09:00` など）が脱落するか、あるいは意図しないローカル時間に変換されるという致命的な不整合を引き起こす。
—
2. 救世主 `DateTimeOffset`：絶対的な「物理的瞬間」の掌握
この混沌を断ち切る唯一の解が、`.NET Framework 2.0`（およびVB.NET 2005）以降に導入された `System.DateTimeOffset` である。
`DateTimeOffset` は、「協定世界時（UTC）からのオフセット（時差）」と「日時（DateTime）」を不可分のペアとして保持する。
.net
‘ 物理的な「その瞬間」を正確に捉える
Dim currentMoment As DateTimeOffset = DateTimeOffset.Now
Console.WriteLine(currentMoment) ‘ 例: 2023-10-25 14:30:00 +09:00
Console.WriteLine(currentMoment.UtcDateTime) ‘ 例: 2023-10-25 05:30:00 (UTCに正規化)
なぜ `DateTimeOffset` が優れているのか？
1. 比較の絶対性: 異なるタイムゾーンで生成された `DateTimeOffset` 同士であっても、`.UtcDateTime` や `.Ticks` に依存せず、直接比較演算子（`=`, `>`, `<`）で「どちらが時間的に先か」を正確に判定できる。 2. システム間連携の堅牢性: JSONやXML、REST APIを介したデータ交換において、タイムゾーンの解釈違いが原理的に発生しない。
—
3. 実務における使い分けの鉄則（アーキテクトの判断基準）
現場でコードレビューを行う際、私は以下の基準で `DateTime` と `DateTimeOffset` の採用を厳格にジャッジしている。
| 適用シナリオ | 推奨型 | 理由 |
| :— | :— | :— |
| データベースの監査ログ / トランザクション日時 | `DateTimeOffset` | 「いつ、どこのタイムゾーンで発生したイベントか」を完全な証拠として残すため。 |
| REST API / Webサービス間のデータ交換 | `DateTimeOffset` | 受信側・送信側でのタイムゾーン解釈のズレを排除するため。 |
| 「毎朝9時に実行するバッチ処理」のスケジュール | `DateTime` (Unspecified) | 物理的な瞬間ではなく、「壁時計の時刻（Wall Clock Time）」に依存するため。 |
| UI上の表示（カレンダーや締め切り日時） | `DateTime` | ユーザーが意図するローカルの時刻をそのままバインドするため。 |
—
4. 実装の極意：レガシー連携とパフォーマンス最適化
ここからは、シニアエンジニアが現場で直面する具体的なユースケースに踏り込む。
パフォーマンスとメモリの最適化
高頻度で呼ばれるループ内や、数百万件規模のバルク処理において、`DateTimeOffset` は `DateTime` よりもわずかにメモリフットプリントが大きい（8バイトのTickに加え、オフセット用の領域やインスタンス生成のオーバーヘッドがある）。
しかし、正確性を犠牲にして得られる数ミリ秒のパフォーマンスに何の意味があるのか？
GC（ガベージコレクション）の圧迫を防ぐため、ループ内での不必要なインスタンス生成を避け、構造体（Value Type）である特性を活かしてスタック上に確実に保持させよ。
Windows API（Win32 API）との連携における罠
レガシーなWindows環境や、古いVB6製DLLとの相互運用（P/Invoke）では、時刻データのやり取りに `SYSTEMTIME` 構造体や `FILETIME` が登場する。これらはタイムゾーン情報を持たない。
以下のコードは、Win32 APIから取得したファイル時刻を、安全に `DateTimeOffset` へ変換する実用的なスニペットである。
.net
Imports System.Runtime.InteropServices
Public Class Win32TimeUtil
Private Shared Sub GetSystemTimeAsFileTime(ByRef lpSystemTimeAsFileTime As Long)
End Sub
”’
”’
Public Shared Function GetCurrentUtcDateTimeOffset() As DateTimeOffset
Dim fileTime As Long = 0
GetSystemTimeAsFileTime(fileTime)
‘ FILETIMEは1601年からの100ナノ秒単位のUTC
‘ DateTime.FromFileTimeはローカルに変換してしまうため、UTCとして直接構築する
Dim dtUtc As DateTime = DateTime.FromFileTimeUtc(fileTime)
‘ 明示的にUTC（オフセット+0）のDateTimeOffsetとして確定させる
Return New DateTimeOffset(dtUtc, TimeSpan.Zero)
End Function
End Class
—
5. ありがちな落とし穴：日時演算の破壊的ミス
最後に、VB.NETでの日時計算における最悪のアンチパターンを指摘する。
✖ 悪い例：タイムゾーンを無視した加算
.net
Dim dtOffset As DateTimeOffset = DateTimeOffset.Now
‘ 加算の結果、サマータイムの境界を跨いだ場合にオフセットが追従しないケースがある
Dim wrongFuture As DateTimeOffset = dtOffset.AddHours(24)
◯ 正しい例：世界標準時（UTC）ベースでの演算、あるいはタイムゾーン考慮
「24時間後（経過時間）」を計算したいのか、「翌日の同じ壁時計の時間」を計算したいのかを明確に意識する必要がある。
.net
‘ 物理的な24時間後を正確に計算する場合（UTCに倒して演算するか、DateTimeOffsetの特性を信頼する）
Dim exactNextDay As DateTimeOffset = dtOffset.ToUniversalTime().AddDays(1)
—
結びにかえて
「動けばいい」の時代は終わった。現代のシステムは、国境を越え、クラウドの底知れぬ仮想空間で稼働している。
VB.NETはそのレガシーな側面から侮られがちだが、フレームワークの深層を理解したエンジニアが書くコードは、極めて堅牢で美しい。`DateTimeOffset` を使いこなし、時間という不確定要素を完全に支配すること。それこそが、プロフェッショナルなアーキテクトの仕事である。
