よくあるタイムスタンプの落とし穴

形式がシンプルに見えても、タイムスタンプは予測可能な方法で失敗します。パターンを認識するとデバッグ時間を節約できます。

Y2038 と整数限界

古典的 32 ビット符号付き time_t は 2038-01-19 付近でオーバーフロー。レガシー組込みと古いバイナリは依然 32 ビット秒を使うことがある。現代 64 ビットサーバーは保存ではほぼ回避するが、エクスポート CSV や古いクライアントはそうでないかもしれない。

JavaScript Date はミリ秒 double — 範囲は巨大だが、パーサーに貼った非常に大きな整数は依然失敗しうる。

1000 倍オフ（秒 vs ミリ秒）

症状:

• 1970-01-01 付近の日付 → 秒をミリ秒として扱った（値が小さすぎ）
• 50000 年超の日付 → ミリ秒を秒として扱った

常に尋ねる: 「このフィールドは sec か ms か文書化されているか？」

曖昧なローカル文字列

タイムゾーンなし 2024-06-01 00:30 は東京とトロントで異なる instant。「サーバーローカル」vs「ユーザーローカル」vs「UTC」としてパースするとバグ報告が大きく変わる。

夏時間の隙間と繰り返し

DST 移行日、ローカル壁時計は繰り返したり飛んだりする。秋の巻き戻し日の「午前 2:30 ローカル」は無効または曖昧なことがある。アラームと課金には UTC instant を保存。

文字列ロケールの驚き

03/04/2024 は US ロケールでは 3 月 4 日、EU では 4 月 3 日。機械可読フィールドでは ISO 2024-03-04 を優先。

要点

多くのタイムスタンプバグは単位混乱、タイムゾーン欠落、レガシー幅限界 — 難解な数学ではない。まずこの 3 つを確認。