时区与 IANA 数据库

像 America/New_York 或 Asia/Shanghai 这样的时区标识符并不是一个显示用的标签——它是一整套规则的名字。它为某个地区记录了曾经生效过的每一个 UTC 偏移量，以及规则改变的确切日期：夏令时何时开始、何时结束，以及底层的标准偏移量本身何时发生了变动。名字里的城市不是为了展示给用户看。它把那段历史锚定到一个地方，这个地方的钟表遵循了一条连贯一致的法律序列。

这就是为什么认真对待时间的软件会存储时区标识符，而不是一个孤零零的偏移量。「UTC-5」告诉你某一瞬间钟表停在哪里；America/New_York 则通过对该日期应用正确的规则，告诉你在任何瞬间——过去或未来——钟表会停在哪里。这些标识符背后的数据库就是 IANA 时区数据库，理解它做了什么，能解释数量惊人的日常怪象。

「区域/城市」命名方案

标识符遵循区域/城市模式：一个宽泛的区域——通常是一块大洲，如 America、Europe、Asia 或 Africa——后跟一个有代表性的城市。America/New_York、Asia/Shanghai、Europe/London、Africa/Cairo。选取那个城市是把它当作规则的稳定锚点，而不是因为它最大或是首都。以 Asia/Shanghai 为例，它管辖整个中国大陆，尽管这个国家横跨的地理宽度本会自然覆盖好几个时区，因为中国实行单一的官方时间。名字标记的是规则的历史，而不是关于地理的断言。

tz 数据库究竟存了什么

tz 数据库——也叫 tzdata 或 zoneinfo，在 IANA 的框架下维护——是一项跨越数十年、力求准确记录民用时间的工作。它由 Arthur David Olson 创立（所以有时仍被称作 Olson 数据库），并长期由 Paul Eggert 编辑维护。它的覆盖以完整的准确度回溯到 1970 年，而且往往更早，捕捉了那些让诚实的日期运算成为可能的历史变动。

因为它存的是历史，而不是单一的当前偏移量，它能回答你墙上的钟无法回答的问题。二十年前，某个国家废除夏令时或改动标准偏移量之前，某座城市在某个特定日期的当地时间是几点？数据库知道，因为它记录的是当时生效的规则，而不是把今天的规则倒推回去。

缩写有歧义；偏移量不是时区

有两个习惯造成了现实中大多数混乱，而 tz 数据库正是为绕开这两者而设计的。

• 缩写会撞车。「CST」不是一个东西。它是美国中部标准时间（UTC-6）、中国标准时间（UTC+8）和古巴标准时间（UTC-5），此外还有别的。一封写着「下午 3 点 CST」的邮件，在不知道发件人指哪个国家的情况下，确实有歧义。而像 America/Chicago 或 Asia/Shanghai 这样的完整标识符不带任何这种歧义。
• 偏移量不是时区。「UTC-5」描述的是某一时刻的偏移量。America/New_York 则是一个在冬季 UTC-5 与夏令时期间 UTC-4 之间交替的时区。存储偏移量会丢掉那条决定未来某个日期该用哪一个的规则；存储时区则保留了它。

偏移量和时区之所以会分道扬镳，根源在于夏令时，而那些 23 小时和 25 小时切换日的机制，在配套指南 夏令时与日期计算 中作了说明。

时区会变，更新一年发布数次

这个数据库并非一成不变。各国会改变主意：废除夏令时、调整标准偏移量，或者拆分与合并时区。每当它们这么做，就会发布一版新的 tzdata——这种情况一年会发生数次，没有固定的时间表，由某个政府何时宣布变动来驱动。随着曾经各异的规则趋于一致，时区也会随时间被重命名或合并，旧名字会作为别名保留下来，好让已有的数据继续能被解析。让这个数据库保持最新，才使得今天创建的一条日历记录，在某个国家明年改动规则之后仍然正确。

AskTheDate 为什么把时区放进 URL

AskTheDate 把一个 IANA 时区嵌进每一个 URL——从 72 个精选时区中选取——因为同一个钟面问题在不同时区里确实有不同的答案。在临近午夜时问「今天几号？」，诚实的回答完全取决于你站在哪里：在 Asia/Shanghai 可能已经是明天，而在 America/New_York 还是今天。把时区烘焙进地址，让每个答案都明确、可分享、可复现——链接本身记录了答案是对着哪个钟计算的，所以无论谁打开它，读到的都一样。

你可以直接看到这种分歧。 纽约时间页面和 上海时间页面在每天的很长一段时间里，会在日历日期上意见不合——这不是 bug，而正是时区存在的全部理由。

试一试

打开 纽约时区转换器， 把一个纽约的深夜时间转换到 Asia/Shanghai。看着日期翻到第二天——这是「值得存储的是时区而非偏移量」这句话最一目了然的演示。