Context: BIPM is responsible for the UTC time standard, and in this document they decide to stop adding (or removing) leap seconds, starting on 20th of May 2027 and lasting for the foreseeable future (until one leap hour is needed). Together with the decision to not add a leap second in December, the 27 leap seconds that have been added so far should be the only ones.
The page lists several good reasons for this, including:
- It's a common source of bugs.
- IoT, embedded systems, and anything that cannot receive time updates have trouble with leap seconds.
- Negative leap seconds have never occurred before, but might occur in the future, and almost no software has tested this case.
I'd also add:
- Unix timestamps are actually defined as "seconds since epoch minus however many leap seconds have happened". It's a hack to make the keep code that assumes 86400 seconds in a day from breaking. It means that during a leap second the Unix timestamp goes back and repeats a previous value, making them ambiguous and non-monotonic.
- Leap second unpredictability can make it impossible to calculate how many seconds are between two UTC dates or Unix timestamps, for example the countdown to the year 2038 bug.
@dan: can we rename this to "BIPM decides to stop adding leap seconds to UTC" or something similar? This title is really downplaying the situation, I think readers over here care a lot about this.
Thank you for providing context for other readers. I was unsure what do to with the title, as my experience is that editorialized titles are always eventually changed to the original title. The "actual" title here is "Resolution 5 (2026)", but I decided to go with the much more specific subheading "On the technical actions needed to ensure the continuity of UTC". Curiously, "On" was removed on submission.
> @dan: can we rename this to "BIPM decides to stop adding leap seconds to UTC" or something similar? This title is really downplaying the situation, I think readers over here care a lot about this.
@-tags like this don't do anything, you're better off sending an email. I think hn@ycombinator.com is the address.
I'm well aware that HN doesn't have @ tags, but I would be surprised if dan doesn't have something listening for this specific string. And not a big enough deal to warrant an email in my opinion, but you're free to send one.
> - Leap seconds make predicting the clock time of timestamps in the future impossible.
I don’t see that reason listed on the page, and future wall-clock times remain unpredictable due to changes in time zone rules.
What will become predictable is the relationship between posix time and elapsed time (in the sense of TAI), at least within the next few hundred years.
Goodbye sundial welcome cesium clock. Astrology app devs: remember to carry the drift in Temporal for the Ascendant, specially around 2267 you might get your love and money life predictions messed up.
> The replacement will not be leap minutes but leap hours.
People have a hard time with leap years, which happen regularly every four years, so I'm curious to know how well a "one-off" event at a basically random time in the future will work.
Am I wrong in interpreting this as just pushing the problem (divergence between International Atomic Time and the rotational speed of the earth) 100 years in the future?
This essentially means being less anal about ensuring the earth has the exact same clock time at the exact same earth-sun-relative rotational position. Turns out the earth spins up and slows down semi-randomly with a magnitude big enough to require positive or negative leap seconds every few years, and it's just not worth the effort. Leap minutes might only be needed around every 100 years, but that would still be annoying, so they dropped all the way to leap hours, probably not needed for thousands of years. As long as the sun rises in the morning and sets in the afternoon, that saves on a lot of frequent minor adjustments. Timezones are already an hour wide anyways, and the sun isn't in the same spot when you're on the western vs eastern edges.
Sure, you could also run a relativistic simulation of the solar system, galaxy, and cosmos to establish a more monotonic clock and calendar independent of imperfect orbital parameters, but that's a bit much for discerning whether or not it's lunchtime.
Several hundred years at least (see my sibling comment). And in all likelihood this will be handled by shifting the time zones by an hour, or possibly by omitting one DST adjustment in spring.
In the very far future, leap seconds would become inadequate anyway, as you’d have to insert them every month, then every week, then every day, due to the deceleration of Earth’s rotation.
The page lists several good reasons for this, including:
- It's a common source of bugs.
- IoT, embedded systems, and anything that cannot receive time updates have trouble with leap seconds.
- Negative leap seconds have never occurred before, but might occur in the future, and almost no software has tested this case.
I'd also add:
- Unix timestamps are actually defined as "seconds since epoch minus however many leap seconds have happened". It's a hack to make the keep code that assumes 86400 seconds in a day from breaking. It means that during a leap second the Unix timestamp goes back and repeats a previous value, making them ambiguous and non-monotonic.
- Leap second unpredictability can make it impossible to calculate how many seconds are between two UTC dates or Unix timestamps, for example the countdown to the year 2038 bug.
@dan: can we rename this to "BIPM decides to stop adding leap seconds to UTC" or something similar? This title is really downplaying the situation, I think readers over here care a lot about this.
FreeBSD tests stuff like this for the code that they take care of:
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
Third-party stuff (like from Ports) is another question.
@-tags like this don't do anything, you're better off sending an email. I think hn@ycombinator.com is the address.
I don’t see that reason listed on the page, and future wall-clock times remain unpredictable due to changes in time zone rules.
What will become predictable is the relationship between posix time and elapsed time (in the sense of TAI), at least within the next few hundred years.
People have a hard time with leap years, which happen regularly every four years, so I'm curious to know how well a "one-off" event at a basically random time in the future will work.
Sure, you could also run a relativistic simulation of the solar system, galaxy, and cosmos to establish a more monotonic clock and calendar independent of imperfect orbital parameters, but that's a bit much for discerning whether or not it's lunchtime.
Barycentric Coordinate Time: https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time
In the very far future, leap seconds would become inadequate anyway, as you’d have to insert them every month, then every week, then every day, due to the deceleration of Earth’s rotation.