Hallelujah! It's quite a shame that this hack had to be used and the logical trichotomy of UTC/UT1/TAI got broken. Computer systems (and UNIX time in particular) should've been using TAI from the beginning with leap seconds being tracked together with time zones, but I guess it's better than the previous mess.
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!
Reading all these reasons sounds like defeat to me. It is sad that in 2026 we cannot even pull off a simple thing like adding or removing a second rarely and long announced to one of our time definitions.
And it's not that we wouldn't have a time without leap seconds. Instead of changing the time definition it would make much more sense to switch to TAI for me. Now we will have tons of UTC code hanging around with support for leap seconds that will never be used and if you want to remove it you will have to distinguish between old and new UTC. Not a fan.
Any prospect for a leap hour is toast by the time we need it. Over a thousand years of ossification will mean our only option is to not care about aligning clock time to the sun. So it's kinda a joke to even talk about leap hours. I'm shocked they're even mentioning such an idea, they should have declared it as a non-solution.
> our only option is to not care about aligning clock time to the sun
No, an easy option is to simply shift every timezone by an hour and keep UTC intact. A ton of places already do that twice a year for daylight savings.
I never understood why we mess with UTC so much when we already have another widely used mechanism to keep the sun and clocks aligned.
Sure, but political timezones shifted by more than 12 hours 65,000 years in the future seems like the sort of thing that would really screw up our existing code. (I wonder what happens if you put such an entry in tzdata right now? Maybe we should put Null Island at +37:00 or something crazy like +1000:00 to start hardening now)
And maybe we should stop touching political timezones by then anyways.
Just define new epoch at the turn of a century. Like a "UTD" or "UT2" that begins like 2200/01/01 00:00 that is actually UTC 2199/12/31 11:43:21 or something. Then hardcode the magic TAI number in the headers along the gravity constant and such. Solves the time_t problem too if done every centuries; 2^32 seconds = 136.102208 years. The biggest concern will be that kids at that time will start asking why there was never been UTB and UTA, which our oldest grandkids wouldn't actually know why.
There is a bit of a fine line between caring about the future and not screwing them over, versus just being so arrogant as to think we know now the right thing to do for them.
But given the amount of time it is going to take to accumulate so much as another leap minute's worth of leap time, let alone an hour, I'm pretty confident we're in the "arrogant" branch if we start declaring what they need.
P(nobody cares about UTC anymore anyhow | someone had to solve the problem of incorporating non-terrestrial time which is way harder than leap seconds) would seem to me to approach 100%. You can decide which branch you want to take, but P(things just keep on keeping on without much change from today for the next several thousand years) seems not large enough to start trying to make lots of plans for.
The resolution doesn't actually mention leap hours, just that the delta is allowed to grow up to one hour. What should happen then is to be decided by future generations.
Heh, I save periodic events as intervals in the database. The upside is it handles weird things like this surprisingly robustly, the downside is that months are months past the start of the year and days are days past the start of the month, yes every thing is zero based. I like it, I feel like I am rebelling against a broken system, but have to make sure I do a conversion to one based months and days for everyone else. Time of day and years are fine, time is already zero based and nobody cares about seeing a year 0.
So the example given Feb-31 is stored as 1 month + 30 days past the start of the year and would trigger right on time march 2nd or 3rd, depending on leap year. In fact I started doing it to handle birthdays on leap day, there is not always a February 29, but there is always a day 29 days after the start of February.
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.
> - 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.
Currently a 'time' is ambiguous if it doesn't come with a timezone. And if it does come with a timezone, then there is no issue with that future shift. You wouldn't redefine EST you'd create an EST2 that was shifted (and which people would colloquially call 'Eastern' after long enough).
So the exact duration between any two times would be easily computed, so long as those times were precise enough to include their timezone-- which they have to be already.
I concur that this is probably a good thing, but UTC without leap seconds already exists. That is TAI and some applications that care about long term persistent and self-consistent telemetry use that.
In simple terms UT1 is the time if we let seconds be defined by the earth's rotation. UTC was kept in sync with this rotation by introducing leap seconds, while still adhering to the stable ticking of TAI (cesium clocks).
From now on UTC will in practice be TAI but with a constant offset (=all previous leap seconds).
> @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.
Thousands of years from now, some entities (be they human or not) will be curious about the idiots who made a decision about timekeeping that makes their life harder. Gods willing, neither Google nor ChatGPT will be in use then, but they will do some kind of search to figure out the rationale and answer the question: "WTF were they thinking?". Perhaps this thread will have been archived for all of time in the great internet data harvest and turn up then. In which case, I say, hello to you from ancient history! We weren't really thinking much at all, to be honest. We're a lazy bunch who mostly does whatever is convenient for us right now, and we tend to let inertia cement the status quo until dealing with problems is 10x harder than a preventative treatment would have been (hope you guys still have a climate!). That's about it. Sorry, chaps. Good luck dealing with this!
Decoupling time from the Earth’s rotation paves the way for the future depicted in Vernor Vinge’s A Fire Upon the Deep, where they use a straight count of seconds since the UNIX epoch, and units like msecs (million seconds ~= 11.5 days).
Hopefully by the time UTC drifts more than an hour from UT1, we’ll be a spacefaring civilization that is happy to treat time as wholly independent from how a particular rock moves.
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.
I knew we wouldn't do a negative leap second. Leap seconds have been in from the start so all software should be able to handle them. But obviously we have no confidence in that actually being true. I suppose it shows that already, pre-AI, we don't really understand everything that we've built.
The mechanism that they have proposed to make this a non issue is interesting. It reads to me as if they are asking another standards body who measures the angle of the Earth's axis relative to the Sun to adjust by a small amount so that leap seconds wouldn't be needed for a period of 100 years.
So now all software engineers should fight with all their power to keep DST where ever possible, so we do not loose the cultural ability to write software that can do the one hour adjustments required by this...
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.
Even in reasonable time zones, significant distance between noon and 12:00 is inevitable. For example, Las Vegas and San Francisco are in the same time zone but one sees the Sun rise about half an hour earlier than the other.
Worrying about a couple of seconds or even minutes is completely insane for almost everyone.
As a sibling comment says it already differs by about 30 minutes over the a year. And it will take roughly 4000 years for the mean solar time to drift about an hour--- so thousands of years for the mean time to dominate the error.
This makes getting a fairly accurate solar time arguably easier, in fact, because you can use a formula correction on top of a stable timebase without first backing out leapseconds which may or may not have been correctly applied.
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.
A chronometer off by one second gives an approximate error of 0.25 nautical miles at the equator. Meanwhile the general precision of celestial navigation is 1-5 nautical miles. If you need high level accurate positioning, celestial navigation is already not an option.
In the open seas, celestial navigation is more than accurate enough. Once you are closer to shore, where the greater precision is needed, better options exists. Lights, ranges, radar, visual, etc.
Julia is not actually doing anything unusual here. When their documentation talks about UT1, this is just a fancy/confusing way of saying that their datetime library isn't aware of leap seconds, just like every other mainstream programming language AFAIK. The abolition of future leap seconds will only reduce the number of weird edge cases this generates, which is all to the good. I suppose they'll need to change the docs, though.
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.
You might not even realize the harm leapseconds have caused you. E.g. almost certainly have knocked your cell service out (or rather prophylactic reboots across leap seconds have)-- and that's without having experienced a negative leapsecond.
Agreed on DST too, both are cases of a small harm done at a such a massive scale that the cumulative damage is significant.
No, because trying to track the sun that closely is a fools task in any case. Even at the dead center of a timezone the time of solar noon differs by a half an hour over the a year.
The leapsecond corrections are to keep an imaginary "mean" solar time in place. But this mean solar time is almost unphysical-- and not observable except through very fancy astronomy.
If you are actually interested in getting an accurate solar/astronomical time leapseconds are something of a hindrance, as you need to back them out to apply formula corrections and there isn't a general way to know if a recent leap second has actually been applied to your timebase (or double applied, or smeared or a spurious one applied...).
> 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.
We know how that would likely work-- should we chose to do it: New timezones are created from time to time for political reasons already and can nicely accommodate this case.
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!
And it's not that we wouldn't have a time without leap seconds. Instead of changing the time definition it would make much more sense to switch to TAI for me. Now we will have tons of UTC code hanging around with support for leap seconds that will never be used and if you want to remove it you will have to distinguish between old and new UTC. Not a fan.
"A minute has 60 seconds" is simple.
"A minute has 59, 60, or 61 seconds. Consult CGPM publications or your national timekeeping authority to find out." is not simple at all.
No, an easy option is to simply shift every timezone by an hour and keep UTC intact. A ton of places already do that twice a year for daylight savings.
I never understood why we mess with UTC so much when we already have another widely used mechanism to keep the sun and clocks aligned.
And maybe we should stop touching political timezones by then anyways.
But given the amount of time it is going to take to accumulate so much as another leap minute's worth of leap time, let alone an hour, I'm pretty confident we're in the "arrogant" branch if we start declaring what they need.
P(nobody cares about UTC anymore anyhow | someone had to solve the problem of incorporating non-terrestrial time which is way harder than leap seconds) would seem to me to approach 100%. You can decide which branch you want to take, but P(things just keep on keeping on without much change from today for the next several thousand years) seems not large enough to start trying to make lots of plans for.
Random local government people declare it is to be, and ... as an industry we largely figure it out.
The more responsible governments give amble notice and as an industry we are very very good at that (you not realizing it, is an example).
And good riddance to leap seconds! It was too hard for us to figure out, and they didn't do anything useful for anyone.
So the example given Feb-31 is stored as 1 month + 30 days past the start of the year and would trigger right on time march 2nd or 3rd, depending on leap year. In fact I started doing it to handle birthdays on leap day, there is not always a February 29, but there is always a day 29 days after the start of February.
... of course you're talking about events that would be approximately 4000 years from now!
On a side note, I really like how the site formatted the reasoning. I'll be copying it to my technical writing.
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.
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.
So the exact duration between any two times would be easily computed, so long as those times were precise enough to include their timezone-- which they have to be already.
So while the political time zones don't change retroactively, the technical rules used in computers can.
From now on UTC will in practice be TAI but with a constant offset (=all previous leap seconds).
@-tags like this don't do anything, you're better off sending an email. I think hn@ycombinator.com is the address.
Hopefully by the time UTC drifts more than an hour from UT1, we’ll be a spacefaring civilization that is happy to treat time as wholly independent from how a particular rock moves.
Worrying about a couple of seconds or even minutes is completely insane for almost everyone.
This makes getting a fairly accurate solar time arguably easier, in fact, because you can use a formula correction on top of a stable timebase without first backing out leapseconds which may or may not have been correctly applied.
Edit...scratch that, now I have to keep track of UT1-UTC as a separately continuously varying parameter provided by IERS instead of tzdata
In the open seas, celestial navigation is more than accurate enough. Once you are closer to shore, where the greater precision is needed, better options exists. Lights, ranges, radar, visual, etc.
This is unfair.
If AI wants to be a coder then it has to do leap seconds. In fact, let's give it leap minutes and leap hours too.
Which doesn't seem like that is soon, but time/calendar issues can creep up and then it's a big hullabaloo:
* https://en.wikipedia.org/wiki/Gregorian_calendar
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.
Leap seconds never did me any harm but DST is a constant menace, adding complexity everywhere.
Agreed on DST too, both are cases of a small harm done at a such a massive scale that the cumulative damage is significant.
The leapsecond corrections are to keep an imaginary "mean" solar time in place. But this mean solar time is almost unphysical-- and not observable except through very fancy astronomy.
If you are actually interested in getting an accurate solar/astronomical time leapseconds are something of a hindrance, as you need to back them out to apply formula corrections and there isn't a general way to know if a recent leap second has actually been applied to your timebase (or double applied, or smeared or a spurious one applied...).
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.