闰秒期间

闰秒临近时，Amazon 提供的两路时间会暂时分开。NTP 时间把额外的一秒摊开，PTP 时间则保留 UTC 的完整闰秒。平日里，它们给出的时间一致；事件期间，说明要求同一个时间客户端不要同时采用它们。这个限制只在很短的窗口里出现，却必须预先写进配置：昨晚还能互换的来源，今天会按不同规则经过同一分钟。问题不在于哪一路时间是假的，而在于两种合法的走法暂时不再给出可以混用的刻度。

另一套程序没有混用两路时间。它把结束时刻减去开始时刻，结果落到了零以下。负值随后进入上游服务器选择，Cloudflare 的部分 DNS 查询失败。程序处理的不是漫长年代，只是一次请求经过了多久；结束不早于开始，原本只是这段计算没有显式检查的前提。UTC 可以在 23:59:59 之后表示 23:59:60，再进入下一分钟。标准已经为额外的刻度留出位置，一次普通减法却未必准备好接住它。第一段的配置要求并没有错，但这次故障没有违反它：规则防住了一种混用，不能因此成为所有闰秒故障的解释。

Google 采用另一种处理，把一秒预先线性分进二十四小时。窗口结束后，时间重新与 UTC 一致；在这段尺度中，结束时刻仍晚于开始时刻，普通耗时计算所依赖的次序得以维持。但摊薄不是让额外的一秒消失。在窗口内，这套时钟会与直接保留完整闰秒的时钟暂时分开；若同一个客户端把两者同时当作可互换的来源，连续性本身也会制造差异。于是 Amazon 同时提供摊薄闰秒的 NTP 时间和保留完整闰秒的 PTP 时间，却仍要求事件期间的同一个客户端只采用其中一路。被保住的是一种运算条件，不是一套能立刻替换所有时钟的答案。

2022 年，国际计量大会决定在 2035 年或之前提高 UTC 与反映地球自转的 UT1 之间的最大允许差。这意味着未来可以在更长时期内不插入闰秒，但并不等于停止闰秒的具体办法已经确定。新的上限和实施方案仍待完成。决议同时确认，数字网络与全球导航卫星系统已经采用不同且未经协调的闰秒处理方法。