摘要

  • 原始 RFC 3339 用 -00:00 表示 UTC 时刻已知、但本地偏移未知；Z 与 +00:00 则表示 UTC 是首选参考。RFC 9557 后来把“本地偏移未知”的含义赋给 Z，同时保留 +00:00 的原义。
  • 归一化到同一时刻，不等于拥有同一份证据。原始字符、解释配置、偏移来源、分数精度、时钟状态、闰秒表、捕获动作与应用结果必须分别留存；字典序只有在 RFC 明列的条件同时成立时才可靠。

同值数据库隐藏了两条历史

想象一个采集系统收到两个不同字符串，解析后都得到同一个 UTC 时刻。为了查询方便，它把二者改写成一条统一格式。排序更容易了，空间也可能更省；但后来调查者再也无法知道生产者最初表达了什么。

RFC 3339 在 2002 年给 -00:00 规定了特殊含义：时刻在 UTC 上已经确定，只是不知道它对应的本地偏移。Z 与 +00:00 则表明 UTC 是该时间的首选参考点。三种形式可以落在同一秒，却对来源背景给出不同回答。

这条设计继承了电子邮件的传统。RFC 2822、以及后来的 RFC 5322，都用 -0000 表示按世界时给出的日期时间，同时明确不提供生成系统的本地时区信息。它没有否认“什么时候”，而是拒绝声称“来自哪个本地时间关系”。

规范更新改变了解释，没有改变时刻

负零偏移在实践中并不顺利。RFC 9557 指出，ISO 8601:2000 及后续版本不允许 -00:00；需要表达本地偏移未知的实现往往改用 Z。2024 年的更新因此重写了 RFC 3339 第 4.3 节的含义。

更新后的 Z 可以表示 UTC 时刻已知而本地偏移未知。+00:00 没有改变，仍表示 UTC 是首选参考。-00:00 也没有被正式废弃，只是为了互操作性，规范建议以 Z 代替。

这使解释版本成为证据的一部分。只存归一化时刻，会丢掉原始符号；只存原始符号而不存使用的配置，又可能让新库用新规则重读旧记录。原始字节、生产者配置、解析器版本和适用标准必须能够相互连接。

规范更新本身并不证明任何产品已经升级。实际部署可能仍采用旧解释，也可能拒绝某种形式。是否落地要由版本、配置和测试回执证明。

数字偏移不是时区身份

RFC 3339 把数字偏移定义为“本地时间减 UTC”。它足以把所写时间换算到同一时刻，却不能指出命名时区、司法辖区、夏令时规则或设备位置。

多个地区在某一天可能共享同一偏移，后来却采用不同转换规则。RFC 8536 的 TZif 格式把转换时刻、本地时间类型、名称和可选闰秒修正另行编码，恰好说明一条数字偏移遗漏了多少状态。

事故对齐时，把记录换算成 UTC 很有用；但它不能证明机器安装了哪一版时区数据库、是否选对区域，也不能证明未来民用时间的意图。那些结论需要配置快照、数据库版本与规则命中回执。

本地偏移未知，不是浮动时间

“偏移未知”容易被误解为“时刻未知”。在 RFC 3339 中恰好相反：UTC 时刻已经知道，缺的是与本地时间的关系。该文档拒绝把无时区限定的本地时间用于一般互联网交换，因为它在世界大部分地区都会得到错误解释。

RFC 5545 的浮动时间是另一种有意设计。比如“无论你在哪里都在 11 点”的日历事件不绑定时区；不同参与者看到相同钟面字段，却可能在不同实际时刻执行。

如果数据模型把二者都写成 timezone_unknown，它就合并了两种完全不同的不确定性。一种知道时刻而缺少本地来源；另一种知道钟面读数，故意让时刻依赖接收者语境。

文本排序只在窄轨道里成立

RFC 3339 希望时间戳有时能直接按字符串排序，但第 5.1 节给出了严格前提：时区必须相同，时区写法必须相同，分数秒的位数也必须相同。只有在这条窄轨道内，字典序才能推出时间顺序。

混合不同偏移、把 Z 与 +00:00 混排、或者同时存一位与六位小数，都已经离开保证范围。基础 ABNF 还允许小写 t 与 z，尽管使用该格式的具体协议可以进一步要求大写。已验证勘误也修正了若干表述和附录语法问题，不能把附录收集的 ISO 语法等同于第 5.6 节的互联网子集。

数据库可以先生成安全的比较键，但必须记录转换规则并保留原文。否则，索引优化就成了不可逆的证据重写。

小数位数证明不了时钟准确度

RFC 3339 只保留了一项少用选项：分数秒。它适合严格排序或特殊精度需求，语法允许一个或更多数字。写得更细，只说明表示粒度更细，并不独立证明时钟更准。

一台未同步设备也能打印九位小数；一个可溯源时钟也可能只输出整秒。RFC 5905 在另一条证据链中描述 NTP 同步、层级、偏差与误差处理。时间戳本身不是 NTP 状态证明。

因此要分别保存写入精度、硬件分辨率、同步来源、最后同步时间、测得不确定度与捕获路径。补零改变的是字符，不是观测质量。

第 60 秒需要外部日程证明

RFC 3339 允许在正闰秒发生的月末边界写出秒值 60，也考虑负闰秒发生时最大值变成 58。语法解析器无法单靠字段范围判断指定日期是否真的安排了闰秒。

RFC 8536 展示了版本化数据里的闰秒修正和时区转换，RFC 5905 则提供时钟协议状态。接受一条含第 60 秒的字符串，只能证明语法层接纳；若未对照权威闰秒表，就不能证明日期成立。

不同时间尺度对闰秒的计数方式也可能不同。比较跨系统日志前，需要保存时间尺度、所用表格和转换函数。一个统一整数若没有这些上下文，反而会掩盖边界。

时间戳从来不是事件回执

RFC 3339 统一的是表示法，不认证生产者，不说明字段何时附加，也不保证它被签名覆盖。签名对象旁边的时间戳可能位于签名范围之外；接收时刻可以晚于捕获时刻；配置错误的时钟也能生成完全合规的未来日期。

完整回执应连接原始字符、解析配置、标准版本、派生时刻、偏移符号、时钟来源与不确定度、闰秒和时区数据、承载对象哈希、密码覆盖、传输接收和应用结果。每一项回答不同问题。

RFC 3339 的历史把原则揭示得格外清楚：同一时刻没有变化，某个表示的标准含义却能被后续文档更新。时间相等，只是时间相等；证据是否等价，必须由保存下来的来源链回答。

来源