こんにちは！開発現場の第一線で戦う、あなたの先輩エンジニアです。
マクロの記録や、なんとなく動くサンプルコードのコピペから一歩抜け出し、「システムの本質を理解して強靭なコードを書きたい」――そう思っている中級者のあなたへ。今回は、実務で必ず直面する「日時（DateTimeとDateTimeOffset）の罠」についてお話しします。
グローバルなシステムや、クラウドサーバー（AWSやAzureなど）とクライアント間でやり取りするアプリを作る際、日付の扱いで頭を悩ませた経験はありませんか？
「あれ？ サーバーに保存したら時間がズレたぞ…？」というバグは、実務で最も多く、そして最も厄介なトラブルの一つです。
ここをクリアすれば、あなたのVB.NETスキルは一段とプロフェッショナルに近づきます。さあ、一緒に本質をマスターしましょう！
—
1. なぜ「DateTime」だけではグローバル時代を戦えないのか？
VB.NETのプログラミングにおいて、日時を扱うとき最初に覚えるのが `System.DateTime` 型ですね。長年、私たち開発者の相棒として活躍してきました。
しかし、`DateTime` 型には致命的な弱点があります。それは「タイムゾーンの文脈が曖昧である」ということです。
楚々とした顔をして牙をむく `DateTime` の正体
`DateTime` 型の内部データは、基本的に「何年何月何日 何時何分何秒」というカレンダー上の数字と、`Kind` というオマケ（`Utc`、`Local`、`Unspecified`）だけで構成されています。
.net
‘ 現在時刻を取得する（ローカル時間になる）
Dim nowDateTime As DateTime = DateTime.Now
‘ この時、Kindプロパティは DateTimeKind.Local になっているが…
Console.WriteLine(nowDateTime.Kind)
この `Kind` プロパティ、実は非常に気まぐれです。
- 別のサーバーにデータを渡したり、JSONシリアライズしたり、データベースに保存・再取得したりすると、この `Kind` 情報が消え去ったり、勝手にローカル時間と解釈されて書き換わったりします。
- 「日本の現在時刻（JST）」として保存したつもりが、UTC（協定世界時）として動作するクラウドサーバー上で読み込まれた瞬間、9時間のズレが発生する……なんて事故が後を絶ちません。
—
2. 救世主 `DateTimeOffset` の登場と仕組み
そこで登場するのが、今回の主役である `System.DateTimeOffset` 型です。
`DateTimeOffset` は、「特定の日時」と「UTCからのオフセット（時差）」を完全にセットで保持する構造体です。
> 【図解的イメージ】
> `DateTime` ＝ 「12月25日 15:00 です（場所の概念が曖昧）」
> `DateTimeOffset` ＝ 「12月25日 15:00 （UTC+9:00 です）」
これによって、「今、地球上のどの地点の何時なのか」が絶対的な値として確定します。
実務で `DateTimeOffset` を使うべき絶対的な理由
1. タイムゾーンの曖昧さがゼロになる： 世界中のどこで処理しても、絶対的な時点を指し示します。
2. データベース（SQL Serverなど）との相性抜群： SQL Serverの `DATETIMEOFFSET` 型と完璧にマッピングでき、DB保存時に時差情報が失われません。
3. ログの信頼性向上： 分散サーバー環境で、どのサーバーで起きたイベントか一意に特定できます。
—
3. 【実践】VB.NETにおける使い分けとコード実装
それでは、実際の開発現場でどのように使い分けるべきか、具体的なコードで見ていきましょう。
シナリオ1：純粋な「日付のみ」「場所に関係ないスケジュール」
例えば、「会社の創立記念日は毎年10月1日」「お店の開店時間は毎日 10:00」といった、タイムゾーンの概念が存在しない（あるいは常にローカルに依存する）データは、従来の `DateTime`（または .NET 6以降なら `DateOnly` / `TimeOnly`）で十分です。
.net
‘ 【DateTimeの適切な使いどころ】
‘ タイムゾーンを考慮する必要がない「ただのカレンダー上の日付」
Dim foundingDate As DateTime = New DateTime(2020, 10, 1)
Console.WriteLine(“創立記念日: ” & foundingDate.ToShortDateString())
シナリオ2：ログ記録、API通信、データベース保存（★実務の主流）
いつ何が起きたか（トランザクション日時やログイン履歴など）を記録する場合は、迷わず `DateTimeOffset` を使います。
.net
Imports System
Module DateTimeMasterClass
Sub Main()
‘ 1. 現在の正確な日時とオフセット（時差）を取得する
Dim currentEventTime As DateTimeOffset = DateTimeOffset.Now
Console.WriteLine(“— ログ記録のサンプル —“)
Console.WriteLine(“記録された日時 (ToString): ” & currentEventTime.ToString())
‘ 出力例: 2023-10-25T14:30:00.0000000+09:00 (ISO 8601形式)
‘ 2. UTC（協定世界時）に変換して保持・送信する（グローバルシステムの鉄則）
Dim utcEventTime As DateTimeOffset = DateTimeOffset.UtcNow
Console.WriteLine(“標準時(UTC): ” & utcEventTime.ToString())
‘ 3. 異なるタイムゾーン（例: ニューヨーク EDT: UTC-4）での表示に変換する
‘ ※実際の実装ではTimeZoneInfoを使用します
Dim tzNY As TimeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById(“Eastern Standard Time”)
Dim timeInNY As DateTimeOffset = TimeZoneInfo.ConvertTime(utcEventTime, tzNY)
Console.WriteLine(“ニューヨーク時間: ” & timeInNY.ToString())
End Sub
End Module
—
4. 陥りがちな罠と、絶対に守るべき「3つの鉄則」
最後に、現場でよくあるミスと、それを防ぐための鉄則を伝授します。ここを知っているかどうかで、エンジニアとしての格が大きく変わります。
罠1：`DateTime.Now` と `DateTime.UtcNow` の混ぜるな危険
コード内で `DateTime.Now` と `DateTime.UtcNow` を比較したり、足し算・引き算をしたりしていませんか？
タイムゾーンが異なるインスタンス同士の演算は、予期せぬバグの温床になります。
> 【鉄則1】日時は必ず UTC（DateTimeOffset.UtcNow）で保持・演算し、画面に表示する直前にローカルタイムに変換せよ。
> データベースに保存する値も、基本はUTCに統一するのがプロの常道です。
罠2：シリアライズ（JSON等）での日付文字列の崩壊
Web APIなどを通じてJSON形式でデータをやり取りする際、`DateTime` だと勝手に解釈されてフォーマットが変わり、受信側でパースエラーになることがあります。
> 【鉄則2】APIのDTO（データ転送オブジェクト）やJSONシリアライズには、ISO 8601形式（`+09:00` などのオフセット情報が含まれる形式）を維持できる `DateTimeOffset` を採用せよ。
罠3：異なる型同士の比較
`DateTime` 型と `DateTimeOffset` 型を直接 ` = ` で比較することはできません。コンパイルエラーになるか、意図しない暗黙的変換でバグを埋め込むことになります。
> 【鉄則3】どうしても既存の `DateTime` と比較する必要がある場合は、`.UtcDateTime` や `.DateTime` プロパティを使って型を明示的に揃えてから比較せよ。
.net
Dim dt As DateTime = DateTime.UtcNow
Dim dto As DateTimeOffset = DateTimeOffset.UtcNow
‘ 比較する時は型の基準を合わせる！
If dt = dto.UtcDateTime Then
Console.WriteLine(“日時は一致しています”)
End If
—
おわりに
いかがでしたでしょうか？
「日付なんて `DateTime.Now` を使っておけばいいや」という時代は終わり、現在はシステムがグローバルに連携する時代です。
`DateTimeOffset` を適切に使いこなせるようになると、時差に起因するクレームや、原因不明のデータズレバグから解放されます。ぜひ次の開発案件から、ログやデータベース保存の標準として `DateTimeOffset` を取り入れてみてください。
ここをクリアしたあなたなら、もう基礎的なVB.NETのコードで迷うことはありません。自信を持って、堅牢で美しいコードを書き上げていきましょう！
