Comment by BoppreH
4 days ago
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.
IMO it's not a simple thing, even at a surface level.
"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.
For thousands of years, we used time synchronized to the sun, with flexible intervals. That’s the natural thing for a lot of things, and that is what UTC is for.
Now, if you don’t care about the sun but about fixed intervals, you can always use TAI.
Standards are there to serve people, and we should have the choice to use the standard that fits our needs best. Changing the meaning of a standard retroactively, with no good reason and when a good alternative is available, is nothing short of irresponsible.
12 replies →
More importantly, in the second case the definition is not static so implementations will inevitably disagree which makes things an even bigger mess.
As I understand it, almost nobody was actually using UTC anyway.
Almost every programming language and database I've ever used assumes 86400-second days, ignoring leap seconds. And one of the popular ways of applying leap seconds was a 'smear' [1] running every clock slightly fast for about 24 hours, rather than having a 61-second minute.
So instead of UTC we actually all use a slightly elastic timescale with the name of UTC, most of the time aligned with UTC, but with the linearity of TAI, and the desirable property that if I'm going to a concert at 19:00 in a year's time and a leapsecond is announced and implemented in the interim, the concert doesn't change to 18:59:59.
[1] https://developers.google.com/time/smear
I have yet to see a single clock able to show 23:59:60. Not just computers, any clock at all
Every system seems to either 1) jump back/forward, 2) smear, 3) ignore it because a drift of more than one second is already accepted in that system
4 replies →
A leap smear for a leap-second insertion needs to run the clock slower, not faster.
> Reading all these reasons sounds like defeat to me.
Agreed.
I never really understood the big issue with these. Systems need to be flexible enough to compensate for clock drift between devices already. On cheap devices like IOT devices (called out in this memo for their lack of capabilities) clocks diverge _all the time_ because cheap timing crystals aren’t great.
Even on expensive desktop PCs, audio and video hardware clocks diverge enough that compensation is required just to watch a YouTube video with the audio synchronized with video all the way to the end, and that’s without Bluetooth devices and the like inserting even more clocks into the system.
If our systems can’t cope with smearing a leap second in either direction every now and then, something is wrong.
I also see this as a defeat. BIPM's Bulletin C announcing the leap second or lack thereof, is almost always very close to full six months before the event. Even this is almost enough time to both develop and test an implementation, not just test it, plus there are usually years of no action between the events.
> Instead of changing the time definition it would make much more sense to switch to TAI for me.
Should UTC permanently stop diverging from TAI, it is more likely that the opposite would happen - TAI would be subsumed by UTC, because there would be no need to maintain two timescales.
Systems which prefer not to deal with discontinuities already use TAI. Many packet capture / timestamping systems natively operate in TAI, and UTC conversion is/can be done in "post-processing". Many / most time servers also do internally, and for example the native time scale for IEEE 1588 / Precision Time Protocol is TAI, and UTC->TAI offset and leap events are announced separately. NTP though, while using its own epoch, is still UTC aligned and while it indicates the LS events, it operates on discontinuous timestamps.
TL;DR: Time sync hard; must make easy.
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.
5 replies →
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.
Surely by then we'll have the technology to simply adjust the Earth's rotation so that it conforms to our standards.
A century later we'll finally be able to fix Earth's orbit to make a nice round 360 days per year, 12 months of 30 days, nice and clean, no more complexity or confusion... ah, that'll be the day.
Reminds me of the old "book the meeting on Feb 31" trick to avoid an unwanted meeting.
3 replies →
A tzdata update. Boom, done.
they should have mentioned leap day instead. or leap month! if we're going for arbitrary long time period predictions, why stop in some 70k years only?
You'd just shift timezones-- which happens from time to time for political reasons and is well supported.
... of course you're talking about events that would be approximately 4000 years from now!
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.
“Stuff FreeBSD does” falls pretty neatly into the “almost no software” category, to be fair.
> - 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.
> if it does come with a timezone, then there is no issue with that future shift.
There is no issue that didn’t already exist, but it remains true that future wall-clock times cannot be predicted with certainty, because tzdata may change between now and the future time.
When someone sets an alarm for 12:00 in five years in the current time zone, how do you store that? It can make a difference whether you store it as a Unix timestamp or as broken-down time plus time zone.
1 reply →
tzdata routinely issues historical corrections in newer versions.
So while the political time zones don't change retroactively, the technical rules used in computers can.
Good, point, I've reworded that bit.
> IoT and anything that cannot receive time updates have trouble with leap seconds.
Could you make an example application where it could be an issue? I imagine it would have to be an appliance that needs high precision time, is not connected to the internet, and hence it has an internal clock that is accurate over long times.
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.
I agree, except that TAI is off from UTC by 37 seconds.
That's a pretty big smear if you want to convert an existing clock from one to the other.
> @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.)
1 reply →
But does that mean that UTC time will diverge from common time zones by more than a fixed number of hours (and minutes for a few esoteric time zones)?
The time zones are defined as UTC + some offset, so no. What UTC will diverge from is solar time (UT1 in the article), so that solar noon might not happen at 12:00 anymore.
But because the sun's trajectory changes throughout the year, and we live in very coarse timezones already, it was always a bit useless tracking this with seconds precision.
> so that solar noon might not happen at 12:00 anymore
The solar noon never happens at 12:00 anywhere anymore. We've left that era about 200 years ago when we synched clocks with the capital city for the benefit of train schedules.
P.S. Well, technically the solar noon happens at 12:00 in New York on January 2nd, Chicago on Jan 14, Denver on Dec 25th, Los Angeles on Jan 9, etc. (on other dates, it's off.) In Santiago de Compostela — where they want to be on the same clock as Warsaw — solar noon happens as "early" as 13:18 and as late as 14:40.
are you saying that we may have a situation where 10:00:10 UTC might be 11:00:11 BST ?
If so I'm failing to see how this is less likely to cause bugs
1 reply →
Is my understanding correct that they maintain a time called UT1, which is basically UTC if it continued to have leap seconds?
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).
> almost no software has tested this case.
This part I simply fail to understand. In the age of CI and formalised approach to testing? What about, simply, "good engineering practices"? What, we look at a (defined, described, standardised) corner case and go "naaah, how likely is that...", and just let it slide? What, if we have a 64-bit counter somewhere, do we go "how likely is that to roll over..."? I f# hope we don't.
In any case, I don't accept the "hasn't been tested" argument. Those mechanisms have been in place for decades now, so what if we had no occurrence. I think this is helpful FUD and buzz generated to accelerate moving away from a slightly cumbersome maintenance event, and I get it, but the "not tested" to me, is (or should be!) an insult to software and hardware engineers out there.
As someone involved in time sync and always on alert during leap seconds (leap second party anyone?), I have mixed feelings here. On the one hand this is less work, but on the other, it is a triumph of reducing complexity - or laziness, dare I say - over "correctness".