日付とタイムゾーン:誕生日が一日ずれる理由

日付、現地時刻、瞬間は別のもの。混同すると、フォームの日付が一日ずれてしまいます。

誕生日には、UTC時差がない

フォームが誕生日を2000-01-01として保存したとします。この値は日付であり、午前0時ともUTCとも、出生地とも書かれていません。これをソフトウェアがUTCの午前0時に変換してロサンゼルスで表示すると、その日のルールでは1999年12月31日の16時になります。変換自体は正しい計算です。誤りはその前、日付を世界共通の瞬間として扱ったところにあります。利用者は最初から瞬間を入力していないのです。

三つの意味を、分けて考える

日付は「何日か」に答えます。現地の日時は「壁の時計が何を示すか」に答えます。瞬間は「共通の時間軸のどこか」を表します。誕生日は通常、一つ目の分類です。「店は9時に開く」には現地時刻のルールが必要で、決済記録には瞬間が必要です。予定には瞬間と、それを説明するタイムゾーンの両方が必要なこともあります。表示形式を選ぶ前に、適切な種類を選ぶと意図を保てます。

読みやすさと、曖昧さのなさ

03/04/2026は、読む人によって4月3日にも3月4日にも見えます。日付の形式2026-04-03なら、順序の曖昧さを避けられます。文章では、読者の言語で月を表すと自然です。瞬間を示すならUTCの印か時差を添えます。2026-04-03T09:00:00Zは特定の瞬間です。末尾のZを省くことは単なる省略ではなく、その時刻を時間軸に置くための情報を失うことになります。

同じ瞬間を、二つの場所で見る

Unixタイムスタンプ946684800を秒として入力してみましょう。UTCでは2000年1月1日ですが、ロサンゼルスの時計では前日です。どちらも同じ瞬間を示しています。次に、年齢計算で生年月日に2000-01-01を入力してみてください。こちらはタイムゾーンでずらさず、日付として扱われます。小さな実装上の区別でも、意味を守る効果は大きいものです。読者に合わせて見せ方を変えても、情報の意味まで変えてはいけません。

直感を試してみよう

2000-01-01を単なる日付として保つために、何を追加する必要がある?

出典・参考資料

独自の解説と計算例を掲載しています。参考リンクは、基になる規格や文書を示しています。

都市・ツールを検索

入力して検索 · Escで閉じる