BIPM decides to stop adding leap seconds to UTC | Hacker News Reader

BIPM decides to stop adding leap seconds to UTC

bipm.org

272 pointsgliffie141 comments

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.

For thousands of years, we used time synchronized to the sun to some approximation that was off by minutes, not microseconds, and nobody cared if the current time relative to the sun was off by a second because they had no way of actually determining that. And then some jerk came along and invented computers and precision timekeeping and suddenly things depended on things like time not appearing to move backwards by as much as a second. :)

UTC is still fixed to the sun. Without leap seconds, it will be hundreds of years before the divergence between UTC and the sun is perceptible in daily life. Even then, I can't think of anything where that would matter.

I think there is a good alternative available, UT1. UTC was always divergent from UT1 anyway, so this change shouldn't affect anyone who actually needs precise solar timekeeping.

More importantly, there are many good reasons to drop leap seconds, such as the massive increase in complexity they impose on all time-related code.

Standards should serve people, which is why leap seconds should never have existed. Imagine: "Sure some airliners crashed, and half the internet went offline for a couple days, but if you drive to the right longitude line, the sun will be exactly overhead at 12:00:00, and here in town it's overhead at 12:23:48. That's worth anything. I'd hate to live in a world where it was overhead at 12:23:49, or that'd be over my great-great-great grandchildren at 12:23:47."

The promise of UTC is bounded deviation from solar time while keeping the intervals of ISO seconds. I think this is a valuable trade-off that should continue to exist.

> I think this is a valuable trade-off that should continue to exist.

And it has, the bound on the deviation was increased slightly to 3600 seconds

I'd prefer if dUT1 was restored to ±.9s after NTP rollover in 2036, Y2K38, and GPS week rollover in 2038. This way we now know precisely what the UTC times will be for those events and dUT1 probably will be <10s at that point. Software will need to deal with times like 23:59:63 properly by then (too much still can't handle 23:59:60 leap seconds yet). Maybe we could have dUT1 < ±9.9s going forward.

The problems with letting dUT1 > 1800 and above is that well before that it starts mattering for almost everything and then you have to consult the solution (here's just 2025's):

  https://crf.usno.navy.mil/quarterly-vlbi-solution

That's generated by the US Navy for all intents and is way more data than used now for leap seconds which are fine enough of a granularity for most things. Future timestamps in UT1 will get difficult to handle as well. Previously software could assume it knew to the closest second which was often good enough.

I'm not sure if I completely follow you, but I'd like to ask: Why is it a problem if there's a divergence between UT1 and UTC? Besides astronomers, who cares if the sun is directly overhead a few minutes later than it "should" be?

Everyone who paid for expensive equipment that gets UT1 time to a tenth of a second in a year or two.

https://www.nist.gov/pml/time-and-frequency-division/time-di...

Nope, the whole point of this is to remove the coupling for UTC. You can either have monotonic time (or at least per-observer monotonic time), or you can follow earth's rotation. Choosing monotonic time is perfectly fine (and feel free to pick your epoch and time unit), but like we have timezones such that 12:00 means something (mostly), having the human conception of what time means does imply that we do kinda need to look at what's happening outside.

We have GMT for standardised solar time. I assume there were good reasons for moving to UTC? Either is fine for many purposes.

So, the thing you probably want for "standardized solar time" is named UT1, there are a bunch of complicated technical details here, which do not matter, but ultimately UT0 and UT2 are not relevant to normal people, UT1 is a hypothetical solar time, estimated by observatories, and UTC is the world's civil time, now fixed to TAI plus 37 seconds.

GMT (Grenwich Mean Time) is a legacy from when Britain (and thus Grenwich, an observatory in London, England) was more important. These days GMT, even in British legislation, just means UTC. When we say "In the winter we use GMT not BST" we're not switching to or from some archaic time system, GMT is just defined as UTC+0 and BST is defined as UTC+1 the same way summer time zones work in several others places which have them.

GP wanted solar time, so that would be old style GMT, which would be now UT1, right?

UT1 is what you'd actually use if you specifically want solar time today, yes.

I'm just highlighting that in most places when it says "GMT" it does not mean solar time, just like how "New Street Station" in Birmingham is not in fact a New Station, or on a New Street, it's a station which was close enough to the road in Birmingham named "New Street" that it's forever associated.

When actual Grenwich Mean Time was "still a thing" astronomers would use it for solar time because we had no better approximations. Today the IERS looks at very distant objects in the sky. We know that in some sense (relative to us) these are not moving because they're incredibly far away, and so we can use them to measure rotation. And then we adjust for where the Sun is from that data.

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

I believe one of the alarm clocks I have owned around the turn of the century could display 23:59:60 and understood leap seconds.

However that's a radio alarm clock which also knows the exact date-time, including year - one of the best presents I have ever received from friends who saw it and realised oh, that is exactly what tialaramex needs. In the smartphone era I do not need one.

It's very rare. I wrote my own clock application to properly see the leap second back in 2015. Here is a recording: https://fedorapeople.org/~mlichvar/leap2015/clock_step.gif

I used to have an oven whose clock would display 23:60 before jumping to 00:01!

Well that's just pure insanity. I have to know this now. I didn't need this :D

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.

In less than half a century, we've created 3 different time standards (TAI, GPS, and now UTC) that tick identically and differ only by arbitrary constant offsets (+37, +18 and +0 seconds). If we haven't come up with an elegant solution by then it's likely 65000 years from now most computing power will be spent running time-conversion libraries.

Time zones change all the time, often on amazingly short notice.

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.

Right, we have the capability to update timezone definitions in a standardized automatable way right now, but 14 hours is the furthest timezone offset a political timezone has ever had. The distant future will require the offset to drift by multiple earth rotations, which puts a wrench in the flexibility of existing systems even if the tzdata database compiles properly. For example, this would break Java's ZonedDateTime as it only supports offsets up to 18 hours.

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.

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.

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.

Treating birthdays on Feb 29 as if they happened on March 1 in non-leap years is wrong in places like California and New York -- at least probably most of the time, because while I already knew that, I didn't appreciate how deep the rabbit hole actually goes.

* https://leginfo.legislature.ca.gov/faces/codes_displaySectio...

* https://www.nysenate.gov/legislation/laws/GCN/58

FWIW, Rare Disease Day is celebrated on Feb. 29.

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.

You store the future alarm as a wall clock time and date plus location, without making any assumptions about what the civil time offset is going to be on that particular date in that location. When the time comes, whatever system has to read your record and raise the alarm will know what the local time is.

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.)

Oops^2. I sent the email, thanks.

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

No, never. BST is defined as UTC + 1 hour. The leap seconds were making both UTC and BST jump around, and now neither will jump around anymore.

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".

The decision not to add leap seconds was already taken. This resolves the remaining issue (the agreement which brings UTC into existence says it tracks solar time, but TAI doesn't actually do that) by kicking this particular can so far into the bushes that our civilisation almost certainly won't ever need to resolve it, while also acknowledging that if you were annoyed by it thousands of years in the distant future you can do a trick so trivial that many places in the world do it twice per year today and barely notice.

The can kicking (inventing a "leap hour" we will almost certainly never use) is what this resolution was about, the decision that leap seconds were a bad idea pre-dates this significantly. Leap hours were always a likely candidate for the can kicking exercise, but I believe there were other possibilities.

>but I believe there were other possibilities.

Imo, the best solution is to just keep every time/date format eternally backwards compatible. And if you do need a change, whether that's leap seconds or daylights saving changes or whatnot: just create a new format

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.

I think about Vinge's treatment of time often. Though I find "see you in a kilosecond" doesn't go down well with the family, so clearly some cultural adjustments needed!

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!

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.

Why the /s? That would be an unironically delightful outcome of widespread belief in astrology. Particle astronomy could use the extra funding!

Because all these delusions are naturally allergic to the concept of empirical evidence.

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.

Solar time never cared about seconds, and leap-seconds were always stupid.

Long overdue. Sad they didn't realize this in 1972 and avoid all the silliness in between.

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.

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.

What do you work on that requires you to care about UT1? Something astronomy-related?

Didn’t Julia choose UT1 for their standard date time library? Although they might want to reconsider with this decision

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.

The clocks we have all basically work in TAI. Historically UTC is TAI plus occasionally a bodge (the leap second) to move it closer to UT1 when it's wrong by too much.

Nobody has a real UT1 clock†, some observation sites prepare guesses at UT1 mostly in terms of how far it deviates from TAI because you can just buy clocks that keep TAI really well.

† You could say this damp rock, "The Earth" is such a clock, and I guess I reluctantly accept that argument but then OK the UI for that clock is abysmal, nobody can use this the way you'd use an actual clock unless they accept miserably bad precision.

The Earth makes for a terribly imprecise clock, but it is the UT1 clock, or rather its defining component.

The UI is a ring laser gyroscope, right?

I’d say most ‘mainstream’ libraries pretend that every day, even a day with leap seconds, has 86400 regular-length seconds. But I thought that within UT1 the length of a second varies every day, so I would not have called that UT1.

Somewhat the inverse, geodesy.

Now when the add a leap second it will be like Y2K. All these systems have not had to deal with that for a century and thus may not be able to deal with a UTC change? Or maybe all software will be auto-updated by hyper intelligence agents and it won't matter.

At this point we really should start working on interplanetary time standards, as well as better handling relativistic time effects. With more and more satellites and computers in deep space it might become a point of failure in the near future.

We have been working on interplanetary (or rather non-earth centric) time standards already for a while. See e.g. Barycentric Coordinate Time, Coordinated Lunar Time, Areocentric Coordinate Time, and related publications.

Is that memo ... technically a single sentence?

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.

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.

China is the largest country with one time zone. It is 5 timezones wide. I guess the western part of China is empty enough that there are no cities that are 4 or 5 hours from Beijing.

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.

Solar noon already varies by up to 30 minutes throughout the year, due to axis tilt and elliptical orbit.

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.

> 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.

We in fact have high confidence that it’s not true. Google started leap smearing back in 2008 because so much broke on leap seconds.

Honestly I’d think a negative leap second would have way higher chances of just working than positive: a positive leap second causes a UTC minute to have a 61st second, and a unix timestamp to repeat. That is a highly rare condition and plays complete havoc on software which does not specifically support these.

A negative leap just means jumping a second, this is already relatively routine due to scheduling and suspends, your program can do one thing and then 20 minutes occur before the next, because right then the user closed their laptop lid.

Yeah, I don't get why negative ones are more scary than positive. I think it's just fear of the unknown because we haven't had one before.

This, I think.

Coming from someone whose daily work has been time sync for years (me):

If you look at Linux and many other Unix and Unix-like systems, to me it's the insertion of a leap second that has more potential for a failure than a removal.

Insertion ("positive leap seconds"): Time formatting functions will output "hh:mm:60" - this in itself is bound to catch some sofware off-guard - but internally during an insertion the same epoch value runs twice: 123456789.999999999 -> 123456789.000000000, which again is bound to cause some amount of confusion to assorted systems, and clearly the smear was implemented to combat this.

Surely this must be worse than the removal ("negative leap seconds"): 123456789.999999999 -> 123456790.000000000 - yes, still a discontinuity, but we have continuous increase and no ":60".

During my time spent developing time sync architectures and software, I tested both, ad nauseam, and tested it for others, a lot, GNSS simulators and all. Clearly precision time sync remains a specialised discipline, and pays my bills, so I don't mind, but I think this is a case of FUD combined with poor engineering practice and inadequate software testing eventually defeating a well-established timekeeping practice that (now this is more poetical than factual) allowed us to keep our timekeeping aligned with "nature".

I actually think we're in for a bigger mess when after this resolution we attempt to big-bang a batch update, but I will be retired and actually more likely dead and gone by the time this happens, so...

"Edit": ...89.999999999 -> ...91.000000000.

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.

TAI already does this. The exact purpose of UTC is to understand the astronomical difference.

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...

It's scary the amount of software that is written that assumes wall clock time is monotonic. Even without leap seconds or DST individual clocks will drift and need to be synced up again using NTP. So we still need to be able to deal with clock changes.

Is this the prelude to dropping UTC altogether?

> Instead of using leap seconds, everyone has agreed that they will tolerate more drift between UTC and UT1 than they had in the past. And when things get really bad, we’ll add a leap hour instead. ... a leap hour won’t be needed for more than 1,000 years

Let me see if I understand this: we are losing accuracy, deliberately, to avoid a negative leap second (something the effects of which we have fears about but don't know), allowing our timekeeping to grow a full hour out of sync, several orders of magnitude worse than we have accepted in the past?

I'm sure there are good reasons, but in terms of communication, this seems lacking. Can someone help me understand why this is better?

It's better for the engineers and normal people because they don't have to keep up with the constant drama of leap seconds and can kick the bucket to the engineers 1000 years in future. Maybe the beings at that time (who knows what we become in 1000yrs) will find some trivial way to deal with it, at least they will have 1000 years to think about it.

> a leap hour won’t be needed for more than 1,000 years

That would mean that, even with a long 100 year lifespan, a person would only experience up to 6 minutes of shift. I feel that's a relatively low value.

Short: no more leap seconds

YYYYYYYYYYYYEEEEEEEEEEEEEEESSSSSSSSSSSSSSSSSSSSS!!!!!!!!!!!!!!!!!!

Praise the maker.

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.

Related. Others?

No leap second will be introduced at the end of December 2026 - https://news.ycombinator.com/item?id=48846281 - July 2026 (244 comments)

Ask HN: Are systems ready for the first negative leap second? - https://news.ycombinator.com/item?id=48807108 - July 2026 (93 comments)

No leap second will be introduced at the end of June 2026 - https://news.ycombinator.com/item?id=47308059 - March 2026 (147 comments)

All I want for Christmas is a negative leap second - https://news.ycombinator.com/item?id=40860831 - July 2024 (257 comments)

Will we have a negative leap second? [pdf] (2022) - https://news.ycombinator.com/item?id=40553027 - June 2024 (72 comments)

How a leap second caused havoc with the Internet (2021) - https://news.ycombinator.com/item?id=39549215 - Feb 2024 (12 comments)

An Update on Leap Seconds (2022) - https://news.ycombinator.com/item?id=34578077 - Jan 2023 (57 comments)

The leap second’s time is up: world votes to stop pausing clocks - https://news.ycombinator.com/item?id=33658541 - Nov 2022 (439 comments)

GPS does not account for leap seconds (2002) - https://news.ycombinator.com/item?id=33620933 - Nov 2022 (53 comments)

It’s time to leave the leap second in the past - https://news.ycombinator.com/item?id=32226414 - July 2022 (583 comments)

Ask HN: How is it that programmers can simply ignore leap seconds? - https://news.ycombinator.com/item?id=29941332 - Jan 2022 (38 comments)

Hate leap seconds? Imagine a negative one - https://news.ycombinator.com/item?id=29924020 - Jan 2022 (108 comments)

Leap seconds: Causing bugs even when they don’t happen - https://news.ycombinator.com/item?id=28046997 - Aug 2021 (172 comments)

GPS will broadcast a 0 second leap second in 128 days. This will cause no issues - https://news.ycombinator.com/item?id=27944776 - July 2021 (41 comments)

Leap second hiatus - https://news.ycombinator.com/item?id=25145870 - Nov 2020 (113 comments)

Leap second 2017 status - https://news.ycombinator.com/item?id=13302404 - Jan 2017 (64 comments)

Some DNS lookups causing 5xx errors due to leap second bug - https://news.ycombinator.com/item?id=13294683 - Jan 2017 (126 comments)

Making every (leap) second count with our new public NTP servers - https://news.ycombinator.com/item?id=13076464 - Dec 2016 (69 comments)

Leap-second decision delayed by eight years - https://news.ycombinator.com/item?id=10603503 - Nov 2015 (23 comments)

Why time may be running out for the leap second - https://news.ycombinator.com/item?id=10506103 - Nov 2015 (25 comments)

AI has become real, and we're cancelling the leap seconds?

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.

I say we make it to deal with leap ticks

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:

* https://en.wikipedia.org/wiki/Gregorian_calendar

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

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...).

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.

If DST is still around in 1000 years, please drop my brain-jar in front of a spacebus.

Leap seconds never did me any harm but DST is a constant menace, adding complexity everywhere.

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.

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.

Nitpick - leap years are every four years except on years divisible by 100 unless they are divisible by 400.

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.

I don't know that people in 1000 years will feel the obligation to follow through with the leap hour at all.

We need to abandon the Gregorian calendar -- it's clearly a software maintenance nightmare -- and return to the Julian calendar.

Sounds like a step in a Fuddruckers > Buttfuckers sequence.

I guess we'll be seeing more and more idiocratic offloading of current problems onto the future generations, contrary to the premise that AI will solve all of them.

Year, we should rather switch to sexagesimal so that children have to memorize a longer multiplication table, and use an hieroglyphic writing system. /s

Reply on news.ycombinator.com