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」，改写偏移。这确实更好，但还不完整——而「更好」和「完整」之间的那段缝隙，正是大部分日历 bug 的住处。

偏移回答的是「那个地方现在几点」。时区回答的是「那个地方以后几点，以及去年几点」。这是两个不同的问题，而只有后者能扛过夏令时。

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. 半小时和 45 分钟是从哪来的

如果缩写不可靠，那偏移本身看着也像随手定的：凭什么印度是 UTC+5:30、尼泊尔是 UTC+5:45，而世界上大多数地方都是整点？

算术很简单。地球 24 小时转 360 度，所以每小时转 15 度——反过来说，一度就是四分钟。时区偏移不过是把经度除以 15。

印度的标准子午线在东经 82°30′，也就是 82.5 度：

82.5 × 4 = 330 分钟 = 5 小时 30 分。

一度自转是四分钟。选在整点之间的子午线，就继承了一个带小数的偏移——这是地理，不是四舍五入。

选这条子午线，是因为它大致落在印度东西两端之间。印度横跨约 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. 一台机器里有两套名字

就算你决定改用城市名，还有一个坑：两大操作系统用的不是同一套名字。

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