EST が曖昧である理由と、代わりに使うべきもの

カレンダーの招待に「14:00 IST」とあります。送り主によって、これは 08:30 UTC でもあり、13:00 UTC でもあり、12:00 UTC でもあります。どれなのかを示すものは文字列のどこにもなく、しかも三つの読みはいずれも正しい用法です。

タイムゾーンの略称は非公式です。割り当てる標準化団体はなく、一意性を保証する団体もなく、いくつかは現在も争われています。文脈を共有する者どうしの会話では差し支えありませんが、それ以外のあらゆる場所では危険です。

効いてくる衝突

IST — 三つの意味があり、いずれも現役です。

意味	オフセット	ゾーン
Indian Standard Time	UTC+05:30	Asia/Kolkata
Irish Standard Time	UTC+01:00	Europe/Dublin（夏季のみ）
Israel Standard Time	UTC+02:00	Asia/Jerusalem

インドとアイルランドは四時間半離れています。誤った IST で押さえた会議は、少し早いどころか、勤務日のほとんどぶんずれます。

CST — 四つの意味があります。

意味	オフセット	ゾーン
Central Standard Time（北米）	UTC-06:00	America/Chicago
China Standard Time	UTC+08:00	Asia/Shanghai
Cuba Standard Time	UTC-05:00	America/Havana
Central Standard Time（オーストラリア）	UTC+09:30	Australia/Adelaide

シカゴと上海は十四時間離れています。

PST — UTC-08:00 の Pacific Standard Time と、UTC+08:00 の Philippine Standard Time。ちょうど十六時間差で、つまり取り違えると暦の日付そのものが変わります。

BST — UTC+01:00 の British Summer Time と、UTC+06:00 の Bangladesh Standard Time。

EST — 北米で UTC-05:00 の Eastern Standard Time。そして歴史的には、AEST が定着する前にオーストラリアが東部州について UTC+10:00 で使っていた略称でもあります。古いオーストラリアの文書は今も裸の形を用います。

もうひとつの問題、略称は季節を指す

略称が一意である場合ですら、それが名指すのは一年の半分だけです。

America/New_York は十一月から三月が EST、三月から十一月が EDT です。したがって七月の「EST」は、存在するどの時計も指していません。その時期のゾーンは EDT だからです。それでも人は「ニューヨーク時間」の意味で書き、字面どおりに受け取ったシステムは七か月にわたって一時間ずれた計算をします。

「EST」がインターネットで最も誤用される略称である理由はここにあります。ある場所の名前として使われていますが、実際にはその場所の季節の名前だからです。

ほとんどのゾーンには略称がない

英語圏のゾーンにはたいてい文字の略称があります。しかしゾーンの大半にはありません。

東京、上海、サンパウロには、どの英語ロケールが用いる ICU データにも文字の略称がなく、「GMT+9」「GMT+8」「GMT-3」として報告されます。日本について「JST」と書かれるのは目にしますし通じもしますが、それは慣習であってデータではありません。

ここでタイムゾーンのツールを作る者に、あからさまな誘惑が生じます。空白を埋めてしまうことです。もっともらしいから「JST」を作り、ブラジルには「BRT」、カトマンズにも何かを。このサイトは意図的にそれをしません。どのロケールも文字を持たない場合は、代わりにオフセットを表示します。このサイトが立てている唯一の約束は、データが当て推量ではなく IANA データベースから来ているということであり、でっち上げの略称こそ、参照物を信用できなくするもっともらしい虚偽の典型だからです。

代わりに何を使うか

IANA 識別子。 America/New_York、Asia/Kolkata、Europe/Dublin。一意で安定しており、季節ではなく、規則の歴史を持つ場所を名指します。

規則変更にも耐えます。2016年にトルコが夏時間を廃止したとき、Europe/Istanbul はトルコを意味し続けました。「EET」や「EEST」を鍵にしていたコードはすべて変更が必要でした。

人に向けて書くときは、都市名とオフセットを示します。「ムンバイの14:00（UTC+05:30）」。どこにいる読み手も、どの IST のつもりだったかを知らずに行動できます。

カレンダーの招待では、ゾーンの付与はカレンダーに任せます。現代のカレンダーはどれも予定にゾーン識別子を保存し、参加者ごとに変換します。タイトルに略称を打ち込む行為は、まさにそれを台無しにします。

API やデータでは、明示的なオフセットまたは Z を伴う ISO 8601 を使い、単に「どのオフセットか」ではなく「どこか」を知る必要があるときは識別子を別に持ち回ります。

それでも読み解かねばならないとき

略称を受け取ってしまい、尋ねられないときは、文脈を使います。

• 誰が送ったか。インドの会社ならインド、アイルランドの会社ならアイルランド。
• どのオフセットなら、その相手にとって提案時刻が筋の通るものになるか。誰も03:00に通話を入れません。
• やり取りの中に都市名はあるか。都市名があれば完全に解決します。

そして重要な場面なら——顧客との通話、締切、デプロイの窓——尋ねてください。「インドですか、アイルランドですか」の十秒は代償より安く、尋ねられた相手もおそらく同じ疑問を抱いていたはずです。

安全な略称

すべての略称が争われているわけではありません。いくつかは実際上一意で、文章の中でなら十分に安全です。ただしコードの中ではやはり違います。

• UTC — 定義上、意味はひとつ
• CEST — Central European Summer Time、一意
• AEDT / AEST — Australian Eastern、A の接頭辞が採用されて以来あいまいさなし
• NZDT / NZST — ニュージーランド
• JST — 日本。データではなく慣習による。ICU はどの英語ロケールについてもこれを持たない

法則に注目してください。安全なのは国名や大陸名の接頭辞が付いたものです。「Eastern Standard Time」は衝突する運命にありました。東を持つ大陸はひとつではないからです。

IANA データベースは略称をどう扱っているか

データベースは略称を確かに記録しており、ゾーンの各期間ごとの項目として持っています。ただし扱いは非公式です。データベース自身の文書が、それらは一意でも標準化されてもおらず、現地の略称が存在しない場所では保守担当者が作った例もあると述べています。

いくつかは作り物であることを理由に、時とともに削除されました。かつて創作された三文字コードを担っていたゾーンは、現在では +0545 のような数値形式を報告します。でっち上げの略称は、正直なオフセットより劣るからにほかなりません。

もっともらしい創作は、欠落を認めることより悪い——その編集上の判断は、このサイトが用いているものと同じです。東京のページの略称欄が JST ではなく UTC+9 と読めるのは、そのためです。