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。

在日历邀请里，让日历自己附上时区。所有现代日历都会把时区标识符与事件一起保存，并为每位参与者做换算。把缩写敲进标题恰恰会毁掉这件事。

在接口和数据里，用带显式偏移量或 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 这样的数字形式——原因正是：编出来的缩写还不如一个诚实的偏移量。

这一编辑判断——看似合理的杜撰比承认缺失更糟——正是本站所奉行的。这也是为什么东京页面上的缩写那一栏写的是 UTC+9，而不是 JST。