タイムゾーンとIANAデータベース

America/New_York や Asia/Shanghai のようなタイムゾーン識別子は、 表示用のラベルではなく、完全なルールセットの名前です。ある地域について、これまで施行されてきた UTCからのオフセットすべてと、ルールが変わった正確な日付——サマータイムがいつ始まっていつ終わるのか、 そして基準となる標準オフセット自体がいつ切り替わったのか——を記録しています。名前に含まれる都市は、 ユーザーに見せるために置かれているのではありません。その歴史を、一貫した一連の法律に従って時計を 刻んできた場所に結びつけるためのものです。

時刻を真剣に扱うソフトウェアが、単なるオフセットではなくタイムゾーン識別子を保存するのはこのためです。 「UTC-5」は、ある一瞬に時計がどこを指しているかを教えてくれます。America/New_York は、過去でも未来でも任意の瞬間について、その日付に正しいルールを適用することで、時計がどこを指すのかを教えてくれます。 これらの識別子の背後にあるのがIANAタイムゾーンデータベースであり、それが何をしているのかを理解すると、 日常の意外なほど多くの奇妙な事象が説明できます。

Area/City という命名スキーム

識別子は Area/City のパターンに従います。まず広い地域——通常は America、Europe、Asia、 Africa といった大陸——があり、続いて代表的な都市が来ます。America/New_York、Asia/Shanghai、Europe/London、 Africa/Cairo。都市は、最大の都市だからでも首都だからでもなく、ルールを安定して結びつけるアンカーとして 選ばれます。たとえば Asia/Shanghai は、国土が自然にいくつものタイムゾーンにまたがる幅を持つにもかかわらず、 中国本土全体を統括しています。中国が単一の公式時刻で動いているからです。名前が示すのはルールの歴史であって、 地理についての主張ではありません。

tzデータベースが実際に保存しているもの

tzデータベース——tzdata や zoneinfo とも呼ばれ、IANAの傘の下で 維持されています——は、市民生活上の時刻を正確に記録しようとする数十年におよぶ取り組みです。Arthur David Olson によって創設され（そのため今でも Olson データベースと呼ばれることが あります）、長らく Paul Eggert によって編集されてきました。その収録範囲は1970 年まで完全な忠実度で遡り、しばしばそれより古く、正直な日付計算を可能にする 歴史的な変更を捉えています。

単一の現在のオフセットではなく歴史を保存しているため、壁の時計には答えられない問いにも答えられます。 ある国がサマータイムを廃止したり標準オフセットを動かしたりする前、20年前の特定の日付に、ある都市の 現地時刻は何時だったのか？ データベースはそれを知っています。今日のルールを過去に投影するのではなく、 当時施行されていたルールを記録しているからです。

略号は曖昧、オフセットはタイムゾーンではない

現実の混乱のほとんどは二つの習慣から生じ、tzデータベースはそのどちらも回避するように設計されています。

• 略号は衝突する。「CST」は一つのものではありません。米国中部標準時（UTC-6）、 中国標準時（UTC+8）、キューバ標準時（UTC-5）などを指します。「午後3時 CST」と書かれたメールは、 送信者がどの国を意味したかを知らなければ本当に曖昧です。America/Chicago や Asia/Shanghai のような 完全な識別子には、そのような曖昧さはありません。
• オフセットはタイムゾーンではない。「UTC-5」はある一瞬のオフセットを表します。 America/New_York は、冬は UTC-5、サマータイム中は UTC-4 と交互に切り替わるタイムゾーンです。 オフセットを保存すると、将来の日付にどちらが適用されるかを決めるルールが捨てられてしまいます。 タイムゾーンを保存すればそれが保たれます。

そもそもオフセットとタイムゾーンが食い違う理由はサマータイムであり、その23時間・25時間の切り替え日の しくみについては、姉妹ガイドの サマータイムと日付計算 で扱っています。

タイムゾーンは変わり、更新は年に数回配布される

このデータベースは固定されているわけではありません。国は考えを変えます。サマータイムを廃止したり、 標準オフセットを動かしたり、タイムゾーンを分割・統合したりします。そうしたとき、tzdata の新しい リリースが配布されます——これは年に数回、決まった暦にはよらず、政府が変更を発表する たびに行われます。かつては別々だったルールが収束するにつれ、タイムゾーンが改名・統合されることもあり、 既存のデータが引き続き解決できるよう、古い名前はエイリアスとして残されます。データベースを最新に 保つことこそ、今日作成したカレンダーの予定が、来年ある国がルールを変えた後でも正しくあり続けることを 可能にしているのです。

なぜAskTheDateはURLにタイムゾーンを入れるのか

AskTheDate はすべてのURLにIANAのタイムゾーンを埋め込んでいます——厳選された72のタイムゾーンのいずれかです——なぜなら、同じ壁時計の問いでも、タイムゾーンが違えば本当に異なる答えになるからです。 真夜中近くに「今日は何日？」と尋ねると、正直な答えは自分がどこに立っているかに完全に左右されます。 America/New_York ではまだ今日でも、Asia/Shanghai ではすでに明日ということがありえます。タイムゾーンを アドレスに組み込むことで、それぞれの答えが曖昧さなく、共有可能で、再現可能になります——リンクそのものが、 どの時計に対して答えが計算されたかを記録しているので、開いた人が誰であっても同じように読めるのです。

その食い違いは直接確かめられます。 ニューヨークの時刻ページと 上海の時刻ページは、一日の大半で暦上の日付について 食い違います——これはバグではなく、タイムゾーンが存在する理由そのものです。

試してみる

ニューヨークのタイムゾーン変換ツール を開いて、ニューヨークの夜遅い時刻を Asia/Shanghai に変換してみてください。日付が翌日へ切り替わるのが 見えるはずです——なぜ保存すべきなのはオフセットではなくタイムゾーンなのかを、一目で示す最も明快な 実演です。