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, but even then it's unclear if they'll do something). 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, ever.
The page lists several good reasons for this, including:
- It's a common source of bugs.
- Solar time is not that important in a world of coarse timezones.
- IoT 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 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.
- The proper ISO8601 formatting of leap seconds ("23:59:60") is widely unsupported, breaking parsers, along with the assumption of how many seconds are in a minute, hour, or day.
---
EDIT: I've emailed hn@ycombinator.com to change the title. It's avoiding editorialization, but I think it's also preventing the post from getting the attention it deserves.
I'm booking a yearly one-second-long holiday on my calendar, to celebrate all the headaches this will save me. Happy end of leap seconds!
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.
They don't care that the dates of the astrological signs have shifted and assign zodiac signs to you that have nothing to do with the constellation of stars at your birth, so I have a feeling they won't care about that either.
Having heard that neutrinos explained the scientific basis of zodiac signs on personality, I'd hope that they'd be more busy trying to set up their underground neutrino detectors /s.
Yay! No more leap seconds to manage! This is going to make my life much easier.
Edit...scratch that, now I have to keep track of UT1-UTC as a separately continuously varying parameter provided by IERS instead of tzdata
It shifts the problem elsewhere, though as you suggest it's sometimes still the same people having to deal with it! For example, anyone relying on celestial navigation who had until now been satisfied with up to 1 second of time error is going to need to start keeping track of UT1-UTC before it starts exceeding those old bounds. This will be possibly within a few years, whenever the next leap second would have been inserted/removed.
What do you work on that requires you to care about UT1? Something astronomy-related?
A practical solution. As long as we can keep 12:00 near high noon and 00:00 near "high midnight(?)", that should be good enough.
We don't even keep very close to that as it is. Between daylight summer time changes and some time zones already being very far off from geography, some places like western Spain or China are already as much as 3 hours off from actual solar time.
After a day of reading AI slop, reading what's essentially an MUN-style resolution, 100% human made, is like eye candy. Thank you for sharing this.
TL;DR: No more leap seconds. The replacement will not be leap minutes but leap hours.
…the next which is expected in roughly a 1000 years: https://www.ucolick.org/~sla/leapsecs/futuredelt.svg
> …the next which is expected in roughly a 1000 years: https://www.ucolick.org/~sla/leapsecs/futuredelt.svg
Which doesn't seem like that is soon, but time/calendar issues can creep up and then it's a big hullabaloo:
It can be handled like DST changes and/or changes in time zone rules. Software based on the tz database should already be able to handle it.
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.
> Sure, you could also run a relativistic simulation of the solar system
Barycentric Coordinate Time: https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time
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.
in 100 years the Sun will be inside the Dyson sphere, so there will be no need for further solar time adjustment
> 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.
The actual rationale here is that it's not worth trying to figure out whether a hypothetical leap hour in a thousand years would be worth it, or how to pull it off if so, because no advance preparation for that scenario that we can do today has enough value to outweigh our ignorance of what the world will look like then. If they decide not to do it, they can just change the rules again; there'll be plenty of advance notice.
Short: no more leap seconds
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.
My first interpretation of the title was that UTC was in danger of something that needed fixing. It didn't occur to me that "continuity" meant in the mathematical sense. But thanks for bringing this to our general attention! It's great news.
On a side note, I really like how the site formatted the reasoning. I'll be copying it to my technical writing.
> - Negative leap seconds have never occurred before, but might occur in the future, and almost no software has tested this case.
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.
> - 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.
Good, point, I've reworded that bit.
> @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.
Dan has confirmed in the past that he doesn’t, and that one should send an email. (Also, usually people use @dang and not @dan.)
Oops^2. I sent the email, thanks.