時刻とタイムゾーン — 保存した「0時」は、どこの0時か

What — 時刻には3つの種類がある

「時刻」とひとまとめに呼んでいる値には、性質の違う3つの種類があります。混ぜると、ずれます。

2026-11-30T15:00:00Z　＝　2026-12-01T00:00:00+09:00

UTC

協定世界時。世界の時刻の基準。日本時間は UTC より9時間進んでいる（+09:00）。

オフセット

UTC からの差。+09:00 など。ある瞬間の差を表すだけで、夏時間の決まりは含まない。

タイムゾーン

Asia/Tokyo のような地域の名前。その地域の時差と夏時間の決まり、その変更の歴史を含む。

夏時間

季節によって時計を1時間進める制度。切り替わる日には、存在しない時刻と2回来る時刻がある。

冒頭の事故で、何が失われたか

Why — なぜ時刻はずれるのか

時刻の値がずれる原因は、ほとんどの場合、計算の誤りではなく、「どこの時刻か」という情報が、途中のどこかで落ちることです。

値は受け渡しのたびに、文字列になり、型が変わり、別の言語に渡ります。その途中で、

• タイムゾーンを持たない文字列に変換される（"2026-11-30 23:00"）
• タイムゾーンを持たない DB の型に保存される
• 受け取った側が、自分のタイムゾーン（サーバーの設定、ブラウザの設定）で解釈する

と、同じ文字列が、受け取った場所によって別の瞬間を指すようになります。

同じ文字列が、書き方しだいで9時間ずれる

JavaScript の Date は、この「どこの時刻か」の扱いが、文字列の書き方によって変わります。

new Date("2026-11-30")        // 日付だけ    → UTC の 0時 として解釈
new Date("2026-11-30T00:00")  // 時刻付き    → 実行環境のタイムゾーンの 0時 として解釈

日本時間の環境では、この2つは9時間違う瞬間になります。仕様どおりの動きですが、見た目がほとんど同じなので、画面の入力をそのまま渡すと気づきません。

夏時間のある地域では、存在しない時刻がある

日本には夏時間がありませんが、利用者や取引先が海外にいると避けられません。

ニューヨークでは、2027年3月14日の午前2時に時計が3時に進みます。その日の 2:30 は存在しません。 秋に戻る日には、1:30 が2回来ます。

• 「毎日 2:30 に実行」は、その日は実行されないか、3:30 にずれる
• 「24時間後」と「翌日の同じ時刻」は、その日だけ一致しない
• 先の日付の予約を、いまの決まりで UTC に変換して保存すると、国が夏時間の制度を変えたときに、予約の時刻が1時間ずれる

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。