タイムゾーンの実際のしくみ

タイムゾーンとは何かとたずねれば、たいていの人は地図上の縦の帯を描写します。世界を二十四の等しい切片に分け、それぞれ一時間ずつ離れ、経度が支配している、と。この模型は整然としていて覚えやすく、そしていずれ会議をひとつ棒に振る形で間違っています。

タイムゾーンとは、ある領域の時計が何を示すかについて政府が保守している、名前のついた規則の集合です。規則は変わりえます。政治的な理由で変わり、経済的な理由で変わり、ときには二週間の予告で変わります。経度はこの考えの出発点であって、行き着いた先ではありません。

この考えはどこから来たのか

1880年代より前、どの町も自前の時刻を守っていました。基準は地方正午——太陽が頭上の子午線を横切る瞬間です。ブリストルはロンドンより十分遅れていましたが、誰も気にしませんでした。十分の差が問題になるほど速く動くものが、まだ何もなかったからです。

鉄道がそれを変えました。列車が10時15分に発つと書かれた時刻表は、10時15分が路線の両端で別の意味を持つなら役に立ちません。1840年代にはイギリスの鉄道会社が自社の路線網全体にロンドン時間を押しつけていました。合衆国は1883年に続き、鉄道会社が自らの判断で国を四つの帯に切り分けました。1884年の国際子午線会議はグリニッジを本初子午線と定め、世界に共通の基準を与えました。

この歴史の要点は、タイムゾーンが調整という問題を解くために、その問題を抱えていた組織自身の手で発明されたということです。太陽がどこにあるかの記述だったことは一度もありません。

ゾーンが実際に持っているもの

権威ある記録が IANA タイムゾーンデータベース、通称 tzdata、あるいはオルソンのデータベースです。テキストファイルであり、年に何度も更新され、あなたが使うすべてのオペレーティングシステム、ブラウザ、プログラミング言語が、そのどれかの版を読んでいます。

各ゾーンについて、次を記録しています。

• America/New_York や Asia/Kathmandu のような識別子
• そのゾーンの歴史の各期間に適用されていた UTC からのオフセット
• そのオフセットが変わる場合、いつ変わるかの規則
• 各期間の略称、存在する場合

識別子は 地域/場所 の慣例に従い、場所は国ではなく代表都市です。国は分裂し、統合し、国境とは無関係に規則を変えるからです。America/Argentina/Buenos_Aires が存在するのは、アルゼンチンの州がかつて互いに異なる時刻を保っていたためです。

ゾーンが何でないかに注意してください。ゾーンはオフセットではありません。America/New_York は「UTC-5」ではありません。オフセットが年の一部で UTC-5、残りで UTC-4 になるゾーンであり、第二次世界大戦中は通年 UTC-5 に留まり、1966年より前は別の規則で動いていたゾーンです。「UTC-5」を保存してそれをニューヨークと呼ぶことこそ、ソフトウェアで最もよくあるタイムゾーンの不具合です。

規則は変わる、しかも段階的にではなく

2016年、トルコは約三週間の予告で夏時間を放棄し、恒久的に UTC+3 に留まりました。2018年、北朝鮮は韓国と足並みをそろえるため時計を30分動かしました。2022年、イランは夏時間を廃止し、同じ年にメキシコが国土の大半で取りやめました。エジプトは2014年に廃止したものを2023年に復活させています。

そのいずれもが tzdata のリリースであり、いずれもがオフセット表を書き込んだシステムをすべて壊しました。このサイトのすべてのページを支える仕組みが、ここに保存された何かではなく実行環境の tzdata からオフセットを読むのは、そのためです。再ビルドが新しい規則を取り込み、編集すべきものは何もありません。

なぜオフセットは整数時間ばかりではないのか

世界人口のおよそ五分の一が、UTC からの差が整数時間でないオフセットの上で暮らしています。インドは UTC+05:30。二つに分けても足りる広さの国に対する、ひとつの妥協として選ばれた値です。ネパールは UTC+05:45 で、この四十五分にはインド時間からの独立を示す意味もあります。チャタム諸島は UTC+12:45、ニューファンドランドは UTC-03:30 です。

オフセットが整数時間だと決めてかかるソフトウェアは、単に丸めるだけでは済みません。何億人もの人に対して30分あるいは45分ずれた答えを返します。それはまさに、通話の前ではなく通話の最中に気づかれる大きさの誤りです。

現地時刻が関数にならない、年に二日

夏時間は年に二つの不連続を生みます。「この現地時刻を変換する」が見た目より難しいのは、そのためです。

進める側は一時間を消します。 ニューヨークでは切り替え当日、01:59:59 の直後が 03:00:00 になります。現地時刻の 02:30 は訪れません。利用者がそれを入力しても、返すべき正しい瞬間は存在せず、代わりに何を返すかという方針があるだけです。

戻す側は一時間を繰り返します。 01:30 は二度訪れます。一度は夏時間で、その一時間後にもう一度標準時で。現地時刻だけでは本当に曖昧であり、どちらの出現を指していたのかを知る必要がありますが、ほとんどの画面はそれを尋ねません。

このサイトのすべてのツールは、どちらの場合も明示的に解決し、何をしたかを伝えます。黙ってどちらかを選ぶことこそ、予定が一時間ずれたまま、通話の瞬間まで誰も気づかない道筋です。

実務上の意味

しくみから三つの規則が導かれ、うまくいかない事柄のほとんどはこれで尽きます。

1. 瞬間を保存し、現地時刻を保存しない。 UTC のタイムスタンプは曖昧さがありません。現地時刻は、タイムスタンプにゾーンを足し、さらに例の二日ぶんの方針を足したものです。
2. ゾーン識別子を保存し、オフセットを保存しない。 Europe/London は規則変更を生き延びますが、UTC+0 は生き延びず、そもそも半年は間違っています。
3. 表示の時点で、実行環境の tzdata を使って変換する。 保存の時点ではなく、そして自分で保守する表からは決して。

このサイトがオフセットについて「最後のビルド時点で」と言い続け、現在時刻をブラウザ側で計算しているのも同じ理由です。あの規則は、私たちが凍結してよいものではありません。