閏秒期間

閏秒臨近時，Amazon 提供的兩路時間會暫時分開。NTP 時間把額外的一秒攤開，PTP 時間則保留 UTC 的完整閏秒。平日裡，它們給出的時間一致；事件期間，說明要求同一個時間客戶端不要同時採用它們。這項限制只會出現在很短的窗口裡，卻必須預先寫進設定：昨晚還能互換的來源，今天會依照不同規則走過同一分鐘。問題不在於哪一路時間是假的，而在於兩種合法的走法暫時不再給出可以混用的刻度。

另一套程式沒有混用兩路時間。它把結束時刻減去開始時刻，結果落到了零以下。負值隨後進入上游伺服器選擇，Cloudflare 的部分 DNS 查詢失敗。程式處理的不是漫長年代，只是一次請求經過了多久；結束不早於開始，原本只是這段計算沒有明確檢查的前提。UTC 可以在 23:59:59 之後表示 23:59:60，再進入下一分鐘。標準已經為額外的刻度留出位置，一次普通減法卻未必準備好接住它。第一段的設定要求並沒有錯，但這次故障沒有違反它：規則防住了一種混用，不能因此成為所有閏秒故障的解釋。

Google 採用另一種處理，把一秒預先線性分進二十四小時。窗口結束後，時間重新與 UTC 一致；在這段尺度中，結束時刻仍晚於開始時刻，普通耗時計算所依賴的次序得以維持。但攤薄不是讓額外的一秒消失。在窗口內，這套時鐘會與直接保留完整閏秒的時鐘暫時分開；若同一個客戶端把兩者同時當作可互換的來源，連續性本身也會製造差異。於是 Amazon 同時提供攤薄閏秒的 NTP 時間和保留完整閏秒的 PTP 時間，卻仍要求事件期間的同一個客戶端只採用其中一路。被保住的是一種運算條件，不是一套能立刻替換所有時鐘的答案。

2022 年，國際計量大會決定在 2035 年或之前提高 UTC 與反映地球自轉的 UT1 之間的最大允許差。這意味著未來可以在更長時期內不插入閏秒，但並不等於停止閏秒的具體辦法已經確定。新的上限和實施方案仍待完成。決議同時確認，數位網路與全球導航衛星系統已經採用不同且未經協調的閏秒處理方法。