摘要

  • RFC 867 规定 Daytime 的端口、传输方式和响应结束方式，却明确说日期没有特定语法；两种示例只是当时流行的写法。
  • 这种空缺是有意的。标准把“机器可用的时间”指向另一个协议 RFC 868，显示文本与计算数值承担不同职责。
  • 后来的互联网时间戳规范固定四位年份、UTC 关系和窄化语法。Daytime 的历史说明：字节能互通，并不等于语义能够由机器唯一还原。

网络成功了，解析仍然没有依据

一台服务器返回 Monday, February 22, 1982 17:37:43-PST，另一台返回 02 FEB 82 07:59:01 PST。人看到两行都知道它们在报时；程序却必须先作决定：年份是两位还是四位，时区前是连字符还是空格，星期字段是否必有，月份能否换语言，星期与日期冲突时相信哪一个？

RFC 867 没有要求任何一种示例格式。它先声明 Daytime “没有特定语法”，再列出两种流行写法。因此，只会解析第二种格式的程序，掌握的是某台服务器的本地约定，并不是一个名为“RFC 867 日期格式”的通用契约。

这不是通信失败。TCP 可以连接、服务器可以发完一行再关闭，UDP 也可以一问一答；每个字节都符合建议，含义仍未获得机器间的一致表达。Daytime 把“运输成功”和“语义可计算”分成了两件事。

两页标准精确规定了什么

1983 年 5 月发布的 RFC 867 把 Daytime 称为调试和测量工具。TCP 版本监听 13 端口，连接建立后发送当前日期与时间的 ASCII 字符串，丢弃客户端发来的任何数据，然后关闭连接。UDP 版本也监听 13 端口；收到任意数据报便返回一个装有当前日期与时间的 ASCII 数据报，请求正文不参与解释。

标准建议只使用可打印 ASCII、空格、回车和换行，并建议回答只有一行。这些规定让操作员能够用最简单的终端或抓包工具直接观察结果，也让客户端知道何时拿到完整回答。

它没有规定字段次序、分隔符、四位年份、小数秒、UTC 偏移、闰秒写法、语言、时钟精度或来源证明。“当前”是服务器对自身时钟的陈述，不是“已经同步”的证书；“ASCII”约束字符集合，不会自动消除日期歧义。

端口号也不能补上这些缺失。注册端口帮助双方识别预期服务，却不授予运营者全球民用时间的权威。数据来自 13 端口，不证明服务器身份，不证明时钟正确，也不证明 PST 在所有接收者那里只有一种解释。

机器时间从另一扇门进来

RFC 867 最后的提示非常明确：机器要使用时间，应采用 RFC 868 的 Time Protocol。后者在 37 端口返回一个固定的 32 位无符号数，表示自 1900 年初以来经过的秒数。Daytime 在 13 端口交付可读的一行；Time 在 37 端口交付统一的数值。

因此，不能把 Daytime 写成一个失败的机器序列化方案。它没有误以为两种示例能支撑通用计算，而是主动把机器需求交给邻近协议。人可以连接远端、确认服务活着、肉眼比较时钟；需要排序和运算的程序则选择数值契约。

同年 10 月的 RFC 880 还记录了当时的地位差异：Daytime 属于 elective，主机可实现也可不实现；Time 属于 recommended，鼓励所有主机实现。这个历史目录不能证明今天的部署量，但能说明可读诊断与机器数值在当时并非同等职责。

固定数值也有自己的边界：它不负责本地显示、时区呈现，后来还需要处理纪元问题。本文不重复已有的 2036/NTP 文章；RFC 868 在这里只承担 RFC 867 自己指定的对照作用。

示例里的星期错了一天

RFC 867 第一种示例原来把 1982 年 2 月 22 日写成星期二，实际是星期一。RFC Editor 在 2025 年核验了 erratum 8551，把 Tuesday 改为 Monday。这是编辑勘误，不是协议升级，也不能说明真实服务器普遍犯错。

它仍提供了一个极其贴题的证据：星期和完整日期在表达同一项日历事实，冗余信息可能彼此矛盾。人能察觉不协调，程序却必须决定哪个字段有优先权。Daytime 没有裁决规则，因为它本来就没有解析语法。

2002 年的 RFC 3339 在设计互联网时间戳时明确讨论了这种问题。它认为星期字段可以与日期不一致，因而不把星期放进机器交换格式；它要求生成四位年份，要求时间与 UTC 的关系可知，并使用数字偏移或 Z，避免依赖互操作性不佳的字母时区缩写。

这不是直接继承关系。RFC 3339 没有取代 RFC 867，2025 年的勘误更不可能反向促成 2002 年的标准。两者只是展示了不同选择：Daytime 让服务器决定显示；RFC 3339 先固定线上表示，再让每个客户端按本地习惯显示。

人类输出怎样悄悄变成接口

可读协议能降低调试成本。RFC 3339 也承认这一点。但不同国家对日期顺序的直觉不一样，面向全球的数据格式不能只依靠屏幕上的自然写法。

Daytime 面向人时并没有矛盾。风险出现在脚本开始抓取这行文字：工程师观察一台服务器，写下正则表达式，仪表盘只保留解析后的时间。没有正式约定，服务器的标点、词汇和时区写法就变成了隐藏 API。

运营者后来改变格式，即使仍完全符合 RFC 867，也可能让脚本失效。这不是服务器违反标准，而是消费者把一次观察提升成了标准从未给出的保证。“过去一直解析成功”只是运行历史，不是协议属性。

可靠自动化只有两条路：把原始行当作不可解释的证据保存，或者另行取得明确的字段语法、时区和失败规则。方便解析一次，不能替代跨实现契约。

IANA 登记不等于公开服务命令

IANA 至今把 TCP/UDP 13 端口登记为 daytime，引用 RFC 867。这项登记维护的是命名空间：观察者知道该端口预期承载什么。它不证明服务仍有部署，不背书其安全性，也不要求运营者向公网开放。

UDP 版本还需要现代风险判断。它不解释请求内容便回应，而 IP 源地址可以伪造。RFC 8085 一般性地警告：未经认证的短请求若触发较大回答，可能被用于放大攻击；运营者应视场景限制回答、限制速率或验证发送者。现有证据没有给出 Daytime 的当前滥用率或统一放大倍数。

所以决策问题不是“这是不是标准端口”，而是“为什么它可达、回答具有什么权限”。TCP 建连不认证时钟，UDP 源地址不认证请求者，一行看得懂的日期也不认证时间真伪。

小标准最重要的是它停下的地方

RFC 867 用极少文字让连接、回答和结束变得可预测，让运维人员很容易直接查看结果，然后明确拒绝定义机器语法。这种克制本身就是设计。

开发者当然能为某一条实际回答写解析器。真正的问题是：标准是否授权他相信这段解析器对所有合规服务器、未来所有合规变化都成立？Daytime 的答案是否定的。

互联网互操作因此不是单一开关。端口可以互通，日期语法仍不互通；字符可以有效，所指时刻仍可能含糊；服务器可以合规，自动化照样失败。读懂一个协议，不只要知道它保证什么，还要知道它主动拒绝保证什么。

来源与证据边界

Daytime 规则来自 RFC 867，示例修正见 RFC Editor 勘误记录。机器数值的对照来自 RFC 868，历史地位来自 RFC 880。

后来的时间戳设计证据来自 RFC 3339；端口治理依据 RFC 6335 和 IANA 服务注册表；现代 UDP 边界来自 RFC 8085。这些资料不提供当前使用率、准确率或攻击统计，也不证明 RFC 3339 是 Daytime 的继承者。