よくある日付パースの落とし穴と回避方法

日付パースの落とし穴

日付パースはソフトウェア開発で最もエラーが発生しやすい分野の一つです。よくある落とし穴とその回避方法を紹介します。

1. タイムゾーン仮定の罠

// 危険：一部のブラウザではUTC、他ではローカルとしてパースされる
new Date("2026-02-28");

// 安全：明示的なタイムゾーン
new Date("2026-02-28T00:00:00Z");     // UTC
new Date("2026-02-28T00:00:00+09:00"); // JST

2. 月-日の曖昧さ

"01/02/2026" — これは1月2日？それとも2月1日？

ロケールを知らなければ、この日付は曖昧です。データ交換には常にISO 8601フォーマットを使用してください。

3. 夏時間のギャップ

DST遷移は存在しない時刻（春の前進）と重複する時刻（秋の後退）を作り出します。

4. 月のインデックス

// JavaScriptの月は0インデックス！
new Date(2026, 1, 28);  // 2月28日（1月28日ではない）
new Date(2026, 0, 28);  // 1月28日

5. 閏年のエッジケース

2月29日は閏年にのみ存在。
2024 — 閏年
2026 — 閏年ではない
2100 — 閏年ではない（100で割り切れるが400では割り切れない）
2000 — 閏年（400で割り切れる）

防止チェックリスト

• パース時には常にタイムゾーンを指定
• データ交換にはISO 8601を使用
• データにロケール依存の月名を使わない
• エッジケースをテスト：閏年、DST遷移、年境界
• 手動の文字列分割よりパースライブラリを優先