【実務・中級編】VB.NETでの日時・時刻演算の落とし穴：DateTimeとDateTimeOffsetの使い分けとタイムゾーン考慮の鉄則 – Visual Basic (VB / VB.NET)解析バイブル

【VB.NET極限最適化】DateTimeとDateTimeOffsetの使い分け：タイムゾーンの罠を断ち切る日時演算の鉄則

開発現場で最も恐れられているバグの一つをご存知だろうか？
それは「日付と時刻の演算ミス」だ。

「単に `Date.Now.AddDays(1)` と書いておけば動くだろう」
「データベースには `DATETIME` 型で突っ込んでおけばなんとかなるだろう」

もしあなたが業務システムの設計においてこのように考えているなら、今すぐその甘い認識を改めなければならない。グローバル展開するシステム、クラウド環境（AzureやAWS）でのコンテナ運用、あるいはサマータイム（DST）を跨ぐスケジュール処理において、そのコードは必ず「時限爆弾」として牙を剥く。

今回は、VB.NETにおける日時・時刻演算の深淵を覗き、`DateTime` と `DateTimeOffset` の本質的な違いから、実務で絶対に踏んではいけない地雷と、その回避策をロジカルかつシャープに伝授する。

—

1. 基礎的誤解の粉砕：なぜ `DateTime` だけでは戦えないのか

VB.NET（.NET Framework / .NET Core）の歴史において、`System.DateTime` は長らく日時の基本クラスとして君臨してきた。しかし、このクラスには構造的な欠陥（あるいは歴史的負債）がある。

`DateTime` が保持する `Kind` プロパティ（`DateTimeKind.Utc`, `DateTimeKind.Local`, `DateTimeKind.Unspecified`）は、あくまで「お気持ち」程度のメタデータに過ぎず、具体的なオフセット（UTCからの時差）を保持していない。

悲劇のシナリオ：ローカル時刻への依存

サーバーの実行環境が変わった瞬間、あるいはOSのタイムゾーン設定が変更された瞬間、`DateTime.Now` をベースにした加算処理は狂い始める。特に、サマータイム（DST）の切り替わり日には、以下のような怪奇現象が発生する。

• 1時間が「消滅」する日（春のDST開始）: 2:00から3:00に時計が進むため、存在しない時刻を指定して演算エラー、あるいは予期せぬズレが生じる。
• 1時間が「重複」する日（秋のDST終了）: 1:00から2:00に戻るため、同じ時刻が2回訪れ、ログの順序が逆転する。

業務システム、特に金融、ログ監視、スケジュール管理において、この「1時間のズレ」は致命傷となる。ここで登場するのが `DateTimeOffset` である。

—

2. 使い分けの鉄則：`DateTime` vs `DateTimeOffset`

実務設計における判断基準は極めてシンプルだ。

| 要件 / 特徴 | `System.DateTime` | `System.DateTimeOffset` |
| :— | :— | :— |
| 保持する情報 | 年月日、時刻、Kind | 年月日、時刻、UTCからの正確なオフセット |
| タイムゾーン | 曖昧（環境依存しやすい） | 厳密（世界どこでも一意に特定可能） |
| データベース連携 | `DATETIME` / `TIMESTAMP` | `DATETIMEOFFSET` (SQL Server等) |
| 推奨用途 | UI表示用の純粋な日付（誕生日など） | ログ、トランザクション、API通信、期限管理 |

チーフアーキテクトからの指令:
「時刻の比較、経過時間の計算、データベースへの永続化を行うデータは、原則としてすべて `DateTimeOffset` で統一せよ。`DateTime` を使っていいのは、タイムゾーンの概念が存在しない『カレンダー上の日付（例：クリスマスの日は毎年12月25日）』を扱う場合のみだ。」

—

3. 【プロダクションコード】バグを駆逐する堅牢な日時演算クラス

それでは、実際の現場で即座に使える、堅牢な日時演算とタイムゾーン変換のサンプルコードを提示する。
このコードは、ログのタイムスタンプ生成、期限切れ判定、そして安全な日数加算を網羅した、保守性の高いVB.NETの実装例である。

Imports System
Imports System.Globalization

Namespace Enterprise.Utilities

”’

Public NotInheritable Class DateTimeManager

‘ プライベートコンストラクタでインスタンス化を抑制（静的クラスとしての設計）
Private Sub New()
End Sub

”’

”’ 基準となるDateTimeOffset ”’ 加算する日数 ”’ 演算後のDateTimeOffset（UTC正規化済み）
Public Shared Function SafeAddDays(baseTime As DateTimeOffset, daysToAdd As Integer) As DateTimeOffset
Try
‘ .NETの DateTimeOffset.AddDays は、内部のTicksベースで安全に計算するため、
‘ サマータイムによる24時間の変動（23時間日や25時間日）を正しく吸収します。
Dim calculated As DateTimeOffset = baseTime.AddDays(daysToAdd)

Return calculated

Catch ex As OverflowException
‘ 日時の範囲外（MinValue / MaxValueを超えた場合）のハンドリング
Throw New ArgumentOutOfRangeException(“加算結果が日時の許容範囲を超えています。”, ex)
End Function
End Function

”’

”’ 日時を表す文字列 ”’ UTCに変換された DateTimeOffset
Public Shared Function ParseToUtc(dateString As String) As DateTimeOffset
Dim parsedResult As DateTimeOffset

‘ ISO 8601 形式や一般的なフォーマットを厳密にパース
If DateTimeOffset.TryParse(dateString, CultureInfo.InvariantCulture, DateTimeStyles.RoundtripKind, parsedResult) Then
‘ 常にUTC（オフセット+00:00）に統一して返却する
Return parsedResult.ToUniversalTime()
Else
Throw New FormatException($”無効な日時フォーマットです: {dateString}”)
End If
End Function

”’

”’ 検証する期限（DateTimeOffset） ”’ 超過している場合はTrue
Public Shared Function IsExpired(targetDeadline As DateTimeOffset) As Boolean
‘ 比較は必ずUTCに揃えて行う。ローカル時刻同士の比較はバグの温床となる。
Dim currentUtc As DateTimeOffset = DateTimeOffset.UtcNow

Return targetDeadline.ToUniversalTime() < currentUtc End Function End Class End Namespace

コードの解説とアーキテクトのこだわり

1. `DateTimeOffset.AddDays` の優位性
内部的に `Ticks`（100ナノ秒単位の整数）で保持されているため、純粋な時間の経過（24時間 × 日数）を正確に計算する。これにより、`DateTime` で発生しがちな「DST切り替え日の時刻スキップによる例外」を回避できる。
2. 必ずUTCへ正規化 (`ToUniversalTime`)
システム間でデータをやり取りする際、オフセットがバラバラの状態で比較すると破綻する。データベースに保存する前、および比較・判定を行う前には、必ず `ToUniversalTime()` を通すのがプロフェッショナルの鉄則だ。
3. `CultureInfo.InvariantCulture` の強制
サーバーのロケール（日本語環境、英語環境など）によって日付のパース挙動が変わるという、現場でありがちな「環境依存バグ」を完全にシャットアウトしている。

—

4. ファイルおよびデータベース連携における注意点

業務自動化ツールにおいて、ファイル（CSV、Excel、JSON）やデータベースとの連携は避けて通れない。ここでも日時の扱いは最大の地雷原となる。

A. データベース連携（SQL Server等）

• NG設計: `DATETIME` 型の列に、VB側の `DateTime.Now` をそのまま突っ込む。
• 正解設計:
• DB側の型は `DATETIMEOFFSET` を採用する。
• VB.NET側でも `DateTimeOffset` を使い、パラメータの型（`SqlDbType.DateTimeOffset`）を明示してバインドする。
• これにより、DBサーバーのタイムゾーンが変わっても、保存された瞬間の「世界標準の絶対時刻」が完璧に維持される。

B. ファイル連携（CSV / JSON）

• NG設計: `2023/10/05 14:30:00` のようにタイムゾーン情報を持たせない文字列でファイル出力する。
• 正解設計:
• 必ず ISO 8601形式（例: `2023-10-05T14:30:00+09:00` または `2023-10-05T05:30:00Z`）でシリアライズする。
• VB.NETであれば `ToString(“o”, CultureInfo.InvariantCulture)` を使用することで、ラウンドトリップ可能な完璧な文字列が出力できる。

—

5. 総括

VB.NETにおける日時演算は、もはや単なる「日付の足し算・引き算」ではない。それはシステムの堅牢性を担保するための 「タイムゾーンガバナンス」 そのものである。

• `DateTime` は表示用と割り切り、演算と永続化には `DateTimeOffset` を使え。
• 比較と保存の前には必ず `ToUniversalTime()` でUTCへ正規化せよ。
• 環境依存のパースを排除し、`CultureInfo.InvariantCulture` を徹底せよ。

この原則をコードに組み込んだ瞬間から、あなたの作る業務システムから「謎の時刻ズレバグ」は永遠に姿を消すことになるだろう。プロフェッショナルとしての誇りを持ち、今すぐ既存のコードベースを点検してほしい。