閏秒のあいだ

閏秒が近づくと、Amazon が提供する二つの時刻は一時的に分かれる。NTP 時刻は余分な一秒をならし、PTP 時刻は UTC の完全な閏秒をそのまま残す。普段なら、それらが示す時刻は一致している。だがイベントのあいだ、説明では同じ時刻クライアントが両方を同時に採用しないよう求めている。この制限が現れるのはごく短い窓の中だけだが、それでもあらかじめ設定に書き込んでおかなければならない。昨夜までは入れ替えて使えた参照元が、今日は同じ一分を別々の規則で通過する。問題はどちらの時刻が偽物かではなく、二つの正当な進み方が、一時的に混用できる目盛りを示さなくなることにある。

別のプログラムは、二つの時刻を混用していなかった。終了時刻から開始時刻を引いたところ、結果がゼロ未満になった。その負の値が上流サーバーの選択に入り込み、Cloudflare の一部の DNS クエリが失敗した。プログラムが扱っていたのは長い年代ではなく、ただ一つのリクエストにどれだけ時間がかかったかだった。終了は開始より早くない、というのは本来、この計算が明示的に検査していなかった前提にすぎない。UTC は 23:59:59 の後に 23:59:60 を表し、それから次の分へ入ることができる。標準はすでに余分な目盛りのための場所を用意していたが、普通の引き算がそれを受け止める準備をしているとは限らない。第一段落の設定上の要求は間違っていない。けれどこの障害はそれに違反したわけではなかった。一つの混用を防ぐ規則だからといって、すべての閏秒障害の説明になるわけではない。

Google は別の処理を採り、一秒をあらかじめ二十四時間に線形に分配する。窓が終われば、時刻はふたたび UTC と一致する。この尺度の中では、終了時刻はなお開始時刻より後にあり、通常の経過時間計算が依存している順序は保たれる。だが、ならすことは余分な一秒を消すことではない。窓の中では、この時計は完全な閏秒をそのまま保持する時計と一時的に分かれる。同じクライアントが両者を同時に交換可能な参照元として扱えば、連続性そのものも差異を生む。だから Amazon は、閏秒をならした NTP 時刻と、完全な閏秒を保持した PTP 時刻を同時に提供しながら、それでもイベント中の同じクライアントにはどちらか一方だけを採用するよう求めている。守られているのは一つの演算条件であって、すべての時計をすぐ置き換えられる答えではない。

2022 年、国際度量衡総会は、UTC と地球の自転を反映する UT1 との最大許容差を、2035 年までに、またはそれ以前に引き上げることを決定した。これは将来、より長い期間にわたって閏秒を挿入せずに済む可能性を意味するが、閏秒を停止する具体的な方法がすでに決まったということではない。新しい上限と実施案は、なお完成を待っている。同決議は同時に、デジタルネットワークと全球測位衛星システムが、すでに互いに異なり、調整されていない閏秒処理方法を採用していることも確認している。