IANA 时区数据库究竟是什么
如果你在软件开发中处理过日期和时间，那你一定依赖过 IANA 时区数据库，无论你是否意识到这一点。它有好几个名字——tz 数据库、tzdata、Olson 数据库或zoneinfo——但它们都指向同一个东西：一个协作维护、免费公开的世界时区及其规则目录。
用“目录”来形容其实有些轻描淡写。这个数据库不仅仅是列出哪些地区位于哪个 UTC 偏移量。它记录的是每个地区民用时间计量的完整历史——每一次偏移调整、每一次夏令时转换、每一次战时时钟调整，以及每一项预定的未来规则——许多情况下可以追溯到 19 世纪中期，当时地方平均时间逐渐被标准化时区取代。当你的日历应用正确显示 1985 年的一场会议比今天相同的时钟时间早了一小时时，这背后就是 tz 数据库在发挥作用。
它基于文本、人类可读且体积小巧。你电脑上安装的编译二进制形式只有几兆字节。然而，它编码了计算领域最隐蔽复杂的数据集之一。
简史
该项目始于 20 世纪 80 年代，由Arthur David Olson发起，他编制了第一个版本，并将其托管在美国国立卫生研究院的服务器上。几十年来，它主要通过一个公共邮件列表协调的志愿工作来维护，这就是为什么旧名称“Olson 数据库”仍出现在文档中。
Paul Eggert接任主要编辑，并长期担任项目协调员。他编写的随附文档 theory.html 以及细致入微的提交历史，使得该数据库既是一份技术参考资料，也是一份历史参考。
2011 年，在经历了一场短暂但令人担忧的关于历史数据的法律纠纷后，管理权移交给了互联网号码分配局（IANA），该机构同样负责协调其他核心互联网资源。IANA 现在发布官方版本，这就是为什么“IANA 时区数据库”成为了规范名称。实际工作仍由同一个贡献者社区完成；IANA 提供了一个机构性家园和一个稳定的分发点。
命名约定：地区/地点
该数据库最显著的特征之一是它命名时区的方式。它不使用国家名称或原始偏移量，而是采用 地区/地点 格式，几乎总是以一个代表性城市为锚点：
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
“地区”通常是一个大洲或海洋（America、Europe、Asia、Pacific），而“地点”是该时区内一个知名城市。这种选择看似古怪，但当你理解其背后的逻辑后，就会觉得合理。
城市是稳定的；政治边界和偏移量则不是。 国家会分裂、合并、改名，并改变它们的时钟。相比之下，城市是一个固定的地理点，拥有连续的时间计量历史。将时区命名为 America/New_York 而不是“美国东部时间”或“UTC-5”，意味着即使附属于它的规则发生变化，这个标识符也依然有效。
该数据库还刻意避免使用国家名称，以回避政治争端，并且因为单个国家通常包含多个时区——美国就有十几个。它在每个不同的时区中选择人口最多或历史意义最重要的城市作为中性标签。当两个地区自 1970 年以来拥有完全相同的时钟历史时，它们共享一个时区；一旦历史出现分歧，它们就会获得独立的条目。
为什么原始偏移量不够用
初学者通常的一个直觉是将时间存储为“UTC+5:30”就完事了。这对于单个时刻是有效的，但一旦你需要推理未来或重复发生的事件时，它就会失效，因为偏移量并非某个地点的静态属性。它们是政府不断且经常突然变更的规则的输出结果。
考虑几个该数据库必须吸收的真实例子：
- 萨摩亚完全跳过了 2011 年 12 月 30 日。 为了使其工作日与澳大利亚和新西兰（而非美国）保持一致，萨摩亚跨越了国际日期变更线，从 UTC-11 变为 UTC+13。对于岛上的任何人来说，那个星期五根本就不存在。
- 国家会在几乎毫无预警的情况下废除、采用或重新安排夏令时。 欧盟一直在争论是否结束夏令时；近几十年来，一些国家和美国多个州已经改变了夏令时规则。土耳其、俄罗斯等国则直接改变了它们的标准偏移量。
- 夏令时开始和结束日期会变动。 美国在 2007 年移动了其夏令时边界。任何硬编码了旧规则的系统，在每年数周的时间里都会默默产生错误的时间。
如果你只存储一个偏移量，你就无法回答“明年 11 月 15 日圣地亚哥的当地时间是什么？”这个问题——因为答案取决于可能尚未最终确定的规则。存储时区标识符（America/Santiago）加上数据库，可以让软件计算任何时刻（过去或未来）的正确偏移量，并在规则变更时自动重新计算。
这就是核心价值主张：tz 数据库将一个地方的身份与决定其时钟的不断变化的规则分离开来。
它是如何维护的
维护工作是在公开环境中进行的。提议的变更——新的夏令时规则、纠正的历史日期、政府公告——会在公共的 tz 邮件列表上讨论，贡献者会引用官方公报、新闻报道和政府法令作为证据。准确性被严肃对待；尤其是对历史数据的更改，会根据原始资料进行仔细审查。
版本发布采用年份加字母的形式：2024a、2024b、2024c 等等。数字是年份；字母在该年每次发布时递增。由于政府按照自己不可预测的时间表宣布时钟变更，因此没有固定的发布节奏——平静的年份可能只有两个版本，而政治动荡的年份则会有多个版本。系统需要及时更新，因为过时的数据库可能意味着在规则变更生效后显示错误的时间。
谁依赖它
几乎是所有东西。
- 操作系统。 Linux 发行版将
tzdata作为核心包提供。macOS 从同一来源获取其时区数据。Windows 出于遗留原因使用自己的基于注册表的时区，但通过 ICU 库和现代 API 暴露 IANA 时区。 - 编程语言。 实际上每一个成熟的日期/时间库都会读取或捆绑 tz 数据库：Python 的
zoneinfo、Java 的java.time、ICU 项目、PostgreSQL、JavaScript 引擎（通过 ICU）、Ruby、PHP 等等。 - 应用程序。 日历、预订系统、金融交易平台、日志分析工具和日程安排服务都依赖它，而开发者通常不会多想。
这种无处不在的特性恰恰说明了该数据库为何如此重要。一个单一的、共享的、精心维护的事实来源意味着，在一个系统中安排的会议可以在另一个系统中正确显示，跨越操作系统和语言，跨越数十年。
如果你想探索这些时区本身，请浏览完整的 IANA时区 列表，或者在我们的 所有时区 目录中查看它们如何映射到全球。
常见问题
tz 数据库与 tzdata、zoneinfo 以及 Olson 数据库是同一个东西吗？
是的。这些都是同一个项目的名称。“tzdata”通常指打包给操作系统使用的数据文件，“zoneinfo”指编译后的二进制目录，而“Olson 数据库”是根据创始人 Arthur David Olson 命名的旧历史名称。如今官方名称是 IANA 时区数据库。
数据库多久更新一次？
没有固定的时间表。发布是由现实世界的事件触发的——政府更改其夏令时规则或标准偏移量，或者对历史数据进行更正。有些年份只有一个版本；其他年份则有多个。每个版本命名为 2024a、2024b 等形式，字母在年内递增。
为什么它用 America/New_York 这样的城市来命名时区？
城市在地理上是固定的，并且具有连续的时间计量历史，而国家、边界和偏移量会随时间变化。使用代表性城市可以为每个时区提供一个稳定的、政治中性的标识符，即使底层的夏令时或偏移规则发生变化，该标识符仍然有效。
我可以只存储 UTC 偏移量而不是时区名称吗？
仅适用于单个固定的时刻。对于未来或重复发生的事件，你应该存储时区标识符，因为偏移量会随着夏令时和政府决策而改变。时区名称加上数据库可以让软件自动计算出任何日期的正确偏移量。
现在谁在运营这个项目？
它由 IANA 发布（IANA 于 2011 年接管管理权），并由 Paul Eggert 与一个通过公共 tz 邮件列表工作的贡献者社区协调。技术工作仍然是协作性、志愿者驱动的。