During the Leap Second

As a leap second approaches, the two time sources provided by Amazon temporarily diverge. NTP time smears the extra second, while PTP time preserves UTC’s full leap second. On ordinary days, the times they return agree; during the event, the documentation says that the same time client should not use both at once. This restriction appears only within a very short window, yet it has to be written into configuration in advance: sources that were interchangeable last night will pass through the same minute today under different rules. The issue is not which time source is fake, but that two legitimate ways of moving temporarily no longer provide scales that can be mixed.

Another program did not mix two time sources. It subtracted the start time from the end time, and the result fell below zero. The negative value then entered upstream server selection, causing some Cloudflare DNS queries to fail. What the program was handling was not a long span of historical time, but simply how long a request had taken; that the end was not earlier than the start had merely been an implicit assumption in this calculation, not an explicitly checked condition. UTC can represent 23:59:60 after 23:59:59, before entering the next minute. The standard has already made room for the extra tick, but an ordinary subtraction may not be prepared to catch it. The configuration requirement in the first paragraph was not wrong, but this failure did not violate it: the rule guards against one kind of mixing, and for that reason cannot become the explanation for every leap-second failure.

Google uses another treatment, linearly spreading one second across twenty-four hours in advance. After the window ends, time once again agrees with UTC; within this scale, the end time is still later than the start time, preserving the ordering on which ordinary duration calculations rely. But smearing does not make the extra second disappear. Inside the window, this clock temporarily diverges from clocks that directly preserve the full leap second; if the same client treats both as interchangeable sources at the same time, continuity itself will produce differences. Thus Amazon provides both NTP time with the leap second smeared and PTP time with the full leap second preserved, yet still requires the same client during the event to use only one of them. What is preserved is a condition for computation, not an answer that can immediately replace every clock.

In 2022, the General Conference on Weights and Measures decided to increase, by or before 2035, the maximum allowed difference between UTC and UT1, which reflects Earth’s rotation. This means that in the future it may be possible to go longer periods without inserting leap seconds, but it does not mean that the specific method for stopping leap seconds has already been determined. The new limit and its implementation plan remain to be completed. The resolution also confirmed that digital networks and global navigation satellite systems have already adopted different and uncoordinated methods for handling leap seconds.