摘要

  • RFC 9636 标准化的是 TZif 文件格式，不是组装其中民用时间规则的来源，也不是规则现行性的证书。
  • 32 位兼容块、64 位转换表、截断边界、footer 和第 4 版闰秒表到期都限定了“算出一个时间”能证明什么。
  • 可审计回执要连接人的意图、时区标识、数据库版本、文件哈希、覆盖区间、读取策略、歧义处理和最终执行结果。

一份时刻表可以印刷正确，却已经不是最新版本。TZif 也一样。

RFC 9636 把 UNIX 系统长期使用的二进制格式写成标准轨道规范，取代 RFC 8536，并新增第 4 版。它明确不定义文件数据从何而来。IANA 时区数据库 是一种重要来源，但 TZif 魔数不会自动证明文件来自 IANA，更不会说明是哪一版。

因此，最终 UTC 偏移量不是充分回执。至少要知道：谁选择了时区、依据哪一版规则、使用哪份文件、读取器走了哪条语义分支，以及应用随后做了什么。

同一文件里的两代世界

每个 TZif 文件先放第 1 版头部与数据块。32 位转换时间只能覆盖约 1901 至 2038 年。第 2 版及以后再附加 64 位头部、数据块和 footer，同时保留旧块供过时读取器兼容。

写入器可以让第 1 版块只剩占位内容。老读取器于是看不到时制变化，新读取器则跳到完整的 64 位数据。“两边都解析成功”并不等于两边消费了同一份时间证据。

生产回执应保存格式版本、读取器版本、实际使用的数据块、长度与索引校验、文件哈希、源数据库和发布版本。只记录“当地时间 09:00”无法在事故后重演当时的计算。

覆盖区间之外，正确答案可以是未知

转换表按时间递增，每条转换选择一个本地时间类型，其中包含相对 UT 的偏移、夏令时标记和缩写索引。类型一直有效到下一条转换。最后一条之后，只有非空 footer 才能继续给出规则，否则未来本地时间未指定。

TZDIST 可以合法地分发截断文件。RFC 9636 要求用边界转换和 -00 占位把未知范围说清楚。开始截断的文件不声称更早时间；结束截断且 footer 为空的文件也不声称更晚时间。

应用若在区间外沿用最后偏移、换用主机默认时区或静默回退到 UTC，实际上新增了一条政策。它可能有业务理由，但不能借文件之名隐藏。

footer 延伸规则，不延伸立法权

第 2 版以上的 footer 可以装入 POSIX 风格规则，在最后一个已存转换之后继续计算。它必须在衔接点与最后转换一致。这只证明文件内部连续。

政府日后改变民用时间安排时，数据源会发布新版。对未来会议或维护窗口，系统必须决定保留原瞬间、原墙上时间，还是要求组织者确认。如果早早只存一个 UTC 数字，人的原始意图就无法恢复。

缩写也不能补救。CST 可指中国、古巴或北美中部时间；相同数值偏移的地区未来也可能分道。时区标识及其选择依据必须与计算一起保存。

第 4 版把知识期限编码出来

第 4 版允许闰秒记录从开头截断，也允许最后一条记录表示闰秒表到期。到期之后，这张表不再说明未来是否会有修正。

读取器可以拒绝处理到期后的时间，也可以忽略到期继续计算并给出错误提示。两种做法都可能符合规范，却支撑不同风险决策。监控不能把它们合并为同一个绿色状态。

第 27 届国际计量大会第 4 号决议讨论未来停止闰秒，但它不会替系统回答：机器装了哪张表、表何时到期、代码选择了拒绝还是继续。制度决定、分发制品与运行分支是三层事实。

安全通道不等于新鲜规则

TZif 自身没有完整性或保密保护。它包含带计数的数组，读取器必须检查块长度、索引和真实文件大小。公共渠道分发需要 TLS 等外部保护，因为被篡改的时区规则足以破坏日历与调度。

TLS 证明一次传输通道，不证明服务端选择了正确数据库版本、缓存仍新鲜，或本地文件后来未被替换。分发回执要包括来源、版本、URL、ETag、获取时间、哈希、缓存年龄和安装结果。

请求某一时区还可能暴露用户过去、现在或未来的位置。规则是公开资料，不代表用户选择是公开资料。

从时间表示到实际执行

RFC 3339表示带偏移的瞬间，RFC 9557可以附加命名时区，RFC 5545描述日历对象。这些信息仍不必然携带准确的 TZif 字节、数据库版本和歧义策略。

时钟回拨时，一个墙上时间可能出现两次；跳变时，某一时间可能根本不存在。转换表揭示结构，应用仍要选择较早、较晚、平移、拒绝或询问。之后还要证明任务真的在决定的瞬间发生。

完整链条依次是：民用意图、时区选择、来源与版本、文件与区间、读取器与策略、渲染结果、应用决定与实际效果。RFC 9636 对字节语义有权威，不对人的地点、未来法律、缓存更新或执行结果拥有权威。

来源