CST は三つの異なる時刻

会議の招待状に「CST 3pm」と書いて、三国に散らばるチームへ送ったとする。

北京の同僚には 15:00 と表示される。シカゴの同僚には 01:00。ハバナの同僚には 02:00。三人、一行、三つの時刻——しかも誰も読み間違えていない。三つとも「CST」の正しい読み方だ。

最初と最後の差は十四時間。丸め誤差でも、夏時間の例外でもない。一日の仕事時間まるごとが、誰もが曖昧さゼロだと信じていた三文字の中に入っている。

これは不注意の話ではない。記法の失敗の話だ。読む人が書き手の居場所を最初から知っている世界のために作られた記法が、その前提を失ったときに何が起きるか。

I. 三文字、四つの場所

CST はこの体系でいちばん混み合った略称だが、特別ではない。

四つの名前、三つのオフセット。しかも CST は ACST（オーストラリア中部標準時）の変種としても広く使われており、これで UTC+9:30 が四つ目として加わる。

IST はもっと整っているが、曖昧さは同じだ。インド標準時が UTC+5:30、イスラエル標準時が UTC+2、アイルランド標準時が UTC+1。三つの名前、三つのオフセット、一つの文字列。

BST はバングラデシュ標準時 UTC+6、ブーゲンビル標準時 UTC+11、英国夏時間 UTC+1。

同じ瞬間、一つの略称に対して三つの正しい読み方。最初と最後の印の間は 14 時間——15:00 引く 01:00。

どれも打ち間違いでも、偶然残った遺物でもない。毎日使われている。公式文書にも、航空時刻表にも、カレンダーの招待にも登場する。

II. 略称は「その場の読者」のために作られた

時計の時差を表す略称は、遠くへ運ばれるために設計されていない。すぐ隣にいる人が読むために作られた。

この書き方は鉄道の時代に生まれた。1883 年、アメリカの鉄道が大陸を四つの標準時間帯に分けたとき、時刻表には極端に短いラベルが必要だった。駅員が細い欄に収められ、乗客が一瞬で読み取れるもの。「CST」はその役目を完璧に果たした。その時刻表を読む人は全員、同じ時間帯にいたからだ。

電報も、商用書簡も、海運の通知も同じ理屈だ。略称が成立したのは、文脈が暗黙のうちに共有されていたからだ。シカゴから届いた手紙に「CST」とあれば、シカゴの受け取り手には当然わかり、ニューヨークの受け取り手も消印から推測できた。

これが略称の本来の機能だ。文脈を指し示すのであって、文脈の代わりにはならない。 文脈を剥ぎ取れば、指し示す先がなくなる。

インターネットは文脈を既定で剥ぎ取る。グループチャットの一行、課題管理システムの一項目、共有ドキュメントの覚え書き——どれも消印を持たない。文字列だけが届き、読み手は手元にある文脈で補う。北京なら UTC+8。シカゴなら UTC−6。どちらも筋は通っていて、その差は十四時間。

はっきりさせておきたいのは、これらの記号を承認した標準機関は存在しないということだ。タイムゾーンの略称は ISO 8601——日時の表記を定める国際規格——には含まれていない。規格の隣で勝手に育ったもので、規格の中には入っておらず、一意性を保証する形で割り当てられたこともない。

III. オフセットはタイムゾーンではない

手っ取り早い修正は「CST」をやめてオフセットを書くことだ。それは確かに改善だが、完成ではない。そして「改善」と「完成」の間の隙間こそ、カレンダーの不具合が棲みつく場所だ。

オフセットが答えるのは「その土地でいま何時か」。タイムゾーンが答えるのは「その土地であとで何時になるか、去年は何時だったか」。別の問いであり、夏時間に耐えるのは後者だけだ。

2024 年に発行された RFC 9557 は、この区別をインターネットのタイムスタンプ規格に初めて明記した。おなじみの RFC 3339 形式の後ろに、角括弧でくくったタイムゾーン名を任意で付けられる：

1996-12-19T16:39:57-08:00[America/Los_Angeles]

オフセットとタイムゾーン名が同時に存在し、冗長ではない。オフセットはこの瞬間を固定し、タイムゾーン名はソフトウェアに他の瞬間への移動のしかたを教える。

名前を欠いたときに何が壊れるか、仕様ははっきり書いている。2020-01-01T00:00+01:00[Europe/Paris] と書かれたタイムスタンプは、六か月進めると七月に正しく着地する。そのときパリは UTC+2 だからだ。同じタイムスタンプを 2020-01-01T00:00+01:00[+01:00]——固定オフセットをタイムゾーンのふりをさせたもの——と書くと、一時間ずれる。パリの時計は決して変わらない、と主張してしまっているからだ。

RFC の文言を直接引いておく。プログラムはタイムスタンプの UTC オフセットをオフセットタイムゾーンに写してはならない。そうすると「その地点のタイムスタンプの UTC オフセットは決して変わらない、と不正に主張する」ことになる。

この一文は、ある種の障害をまとめて説明している。固定オフセットから計算した「来四半期」の会議は、夏時間の切り替えをまたげば一時間ずれる。記録した時点でオフセットは正しく、使う時点で間違っている。

IV. 半端な分はどこから来るのか

略称が当てにならないとして、オフセット自体も気まぐれに見える。なぜインドは UTC+5:30 で、ネパールは UTC+5:45 なのか。世界の大半は正時なのに。

計算は単純だ。地球は 24 時間で 360 度回る。つまり一時間に 15 度、1 度は 4 分。タイムゾーンのオフセットは、経度を 15 で割ったものにすぎない。

インドの標準子午線は東経 82°30′、つまり 82.5 度：

82.5 × 4 = 330 分 = 5 時間 30 分。

自転 1 度は 4 分。正時の間に子午線を選べば、端数のついたオフセットを引き継ぐ。これは地理であって、丸めではない。

この子午線が選ばれたのは、インドの東西の端のほぼ中間にあるからだ。インドは経度で約 29 度、分に直すと 116 分——西端と東端の太陽時の差は二時間近い。中央の子午線を取れば、その不便を片側に押しつけずに済む。

ネパールは同じ論理をもう一歩進めた。カトマンズの地方平均太陽時は UTC+5:41:16。ネパールは UTC+5:30 に丸めず、1986 年に時計を 15 分進めて UTC+5:45 に落ち着いた。地域の太陽時に近く、しかも隣のインドとは意図的に揃えない。

世界で 45 分のオフセットを使う時間帯は三つだけ。ネパールの UTC+5:45、チャタム諸島の UTC+12:45、そしてオーストラリア西部の非公式な UTC+8:45 だ。端数のオフセットは珍しいが、誤りではない。国が「その土地の正午に意味を持たせたい」と決めた結果にすぎない。

V. タイムゾーンの名前は政治的な決定だ

端数のオフセットは地理から来る。残りの大半は政治から来る。

中国が最もわかりやすい例だ。1918 年に提案され、1947 年に正式採用された区分では、国土は五つの時間帯に分かれていた。崑崙が UTC+5:30、新蔵が UTC+6、隴蜀が UTC+7、中原が UTC+8、長白が UTC+8:30。東西の差は三時間。

1949 年、新政権は全国を UTC+8（北京時間）に統一し、五つの時間帯は消えた。最西端の新疆は揺れ続けた。1969 年から 1986 年のあいだ、独自の UTC+6 と北京の UTC+8 の間を何度も往復し、最後に北京時間へ落ち着いた。

中国は 1986 年から 1991 年まで夏時間も実施し、その後やめた。「中国に夏時間はない」は現在は真、六年前までは偽、そして太陽ではなく政策についての事実だ。

インドの歴史も同じ形をしている。1906 年 1 月 1 日に単一の標準時を採用する前、亜大陸には少なくとも三つの公式時刻が走っていた。ボンベイ時間が UTC+4:51、カルカッタ時間が UTC+5:53:20、マドラス時間が UTC+5:21:14。ボンベイは 1955 年まで独自の時刻を保った。国標準ができてから四十九年後である。

教訓は、当時のこれらの国がずさんだったということではない。タイムゾーンは行政の境界であって、幾何の境界ではないということだ。ある土地のオフセットは、その政府が最後に決めた値であり、政府は決定を変える。

IANA データベースが国名ではなく都市名を使うのも同じ理由だ。Asia/Shanghai は上海だけでなく中国全土を覆う。名前は時間帯の由来を示すのであって、範囲を示すのではない。「上海の時刻」と読んだ人は、答えは合っているが理由が違う。

VI. 一つの機械に二つの命名体系

都市名を使うと決めても、罠はもう一つある。二大 OS が同じ名前を使っていない。

IANA データベース——ほぼすべてのサーバー、スマートフォン、プログラミング言語の背後にあるもの——は中国の時間帯を Asia/Shanghai と呼ぶ。Windows は同じ時間帯を China Standard Time と呼ぶ。どちらも自分の体系では正しく、相手の体系では無効だ。

影響が出るのはデータパイプラインだ。Windows 上で動くサービスが China Standard Time をデータベースに書き、Linux 上で動く集計ジョブが読み出せず、黙って UTC にフォールバックする。タイムスタンプは八時間ずれ、例外は一つも投げられない。

解決は技術ではなくルールだ。保存は IANA 名、変換は境界で。 IANA 名はこの業界で汎用識別子に最も近いもので、公開の場で保守され、どの言語とデータベースも解決できる。

VII. 輸送に耐える時刻の書き方

三つのルールでほぼ全部をカバーできる。

オフセットを書く。略称は書かない。 09:30 UTC+8 は読み違えようがない。09:30 CST は三通りに読み違えられる。プレーンテキストしか入らない欄なら、オフセットが実用上の下限だ。

あとで使う時刻には時間帯の名前を足す。 予定、繰り返し、保存するものは 09:30 Asia/Shanghai と書く。オフセットは今日正しい。時間帯の名前は、夏時間の切り替えや将来の規則変更を越えても正しい。

裸の略称を国境の外へ出さない。 一国の内部、全員が地理を把握している場なら「CST」で問題ない。それは昔も今も変わらない。メッセージが国境を越えた瞬間、略称は展開しなければならない。

会議の話なら、本文に時刻を書かないのが確実だ。本当のタイムゾーンが付いた招待を送るか、両側を同時に見せる変換ツールを使う。当サイトのタイムゾーン変換と世界時計はまさにそのためにある。二都市を選び、重なる時間を見て、夏時間の切り替えをまたぐ日にどうなるかを確認してから決められる。

契約の話なら、時間帯の名前とオフセットを並べて書き、両者が食い違ったときにどちらが優先かを明記する。「北京時間午後 5 時（UTC+8）」は今日も曖昧でなく、次の規則変更のあとも曖昧でない。

VIII. 略称は「文脈の共有」についての主張だ

招待状に戻ろう。三文字、三つの正解、十四時間の隔たり。誰も不注意ではなかった。この記法が、果たせない約束をしたのだ。読み手と書き手は同じ場所にいる、という約束を。

その約束は一世紀のあいだ保たれた。ほとんどのメッセージが遠くへ行かなかったからだ。鉄道の時刻表、電報、消印のある手紙——どれも自分の地理を抱えて運ばれた。インターネットは梱包を外し、ラベルだけを残した。

だから「CST」の正しい読み方は、タイムゾーンとして読むことではなく、差出人はあなたが自分の居場所を知っていると思っているという主張として読むことだ。その主張が正しいこともある。正しくないときの代償は、要領を得ない会議ではない。乗り遅れた飛行機であり、壊れたリリース作業の時間帯であり、二人の弁護士がどちらも正しく読みながら争う契約書だ。

時刻は決して数字だけではない。数字と場所だ。略称は場所を省こうとする試みであり、それこそが失敗の理由である。

参考資料

• List of time zone abbreviations：CST、IST、BST のすべての意味とオフセット
• RFC 9557: Date and Time on the Internet：角括弧によるタイムゾーン名の注記と、固定オフセットでは足りない理由
• Time in China：1949 年以前の五つの時間帯、1949 年の統一、1986–1991 年の夏時間
• Indian Standard Time：ボンベイ・カルカッタ・マドラス時刻と東経 82°30′ 子午線
• Nepal Standard Time：カトマンズの地方平均太陽時と 1986 年の UTC+5:45 への変更
• Default Time Zones：Windows のタイムゾーン識別子（China Standard Time を含む）