No leap second will be introduced at the end of June 2026

We've had 27 leapseconds in the last 54 years [1] - an average of 0.5 seconds per year.

At that rate, solar time will drift by 60 seconds over the course of 120 years. Drifting by 10 minutes will take 1200 years.

The leap hour will be in 7200 years, around year 9226.

[1] https://en.wikipedia.org/wiki/Leap_second

Leap hour replaces all of that with what is more or less equivalent to a change in DST rules (except for more time zones at once). DST changes don't go perfect either by any means... but we do them regularly enough without the world crashing down that doing an additional shift change of an extra hour every 5000 years is almost certainly less hassle and breakage than the leap second approach breaking things every ~2 years.

The leap seconds were an attempt to have wall clock time map to the planet's rotational angle consistently despite the problem that the planet's spin varies unpredictably.

Yes the "leap hour" is a legal fiction of course. In reality in the event anybody cares about this in the distant future they will make the kind of "drastic" changes you've probably experienced twice a year for your whole life and barely noticed... More likely because the drift is so incredibly slow they won't change anything.

A simpler solution: we already have an offset between local time and coordinated time, just change that offset. So, for instance, Brasília Time, which is currently UTC-03, would become UTC-02 or UTC-04, depending on which way the change went.

For the time of Julius Caesar, about 3 more days would have been needed, which would have made the Christmas coincident with the Winter Solstice, and which would have made much more sense.

The concern, of course, is that some universes eliminating them while others don't can puts us out of sync. This creates a wobble that could potentially throw us out of Hilbert space.

Note that the equinoxes and solstices are officially supposed to be on the 25th. By the time of Julius Caesar, that had diverged, but the divergence in reality made no impact on the date of the official solstice. The Gregorian calendar could easily have put the solstices back on the 25th, but chose not to.

<rant> It won't happen on a human scale. So why oh why do we screw around with this moronic leap-second nonsense ? Oh dear, in the year 4000 noon will arrive three minutes earlier compared to now. So? </rant>

“Over time” really glosses over how much time it would take. In 500 years there might be half as much divergence between solar noon and 12:00pm as we intentionally inflict on ourselves with DST, or that France and Spain inflicted on themselves in the 1940’s so they could share a time zone with Germany. By the time anyone will even notice we will probably change time systems for other reasons anyway. It’s not even remotely comparable to the Julian/Gregorian issue, which dealt with leap days. Each day has 86400 seconds.

I wonder if all NTP implementations don't follow those guarantees?

Oh and another app that hates clock jumps used to be sshd; it would just bail out and drop all connections. We found that out while chasing ANOTHER bug in SunOS on a T4: they didn't have it mutexed right so it possible to read its RTC register while it was in the middle of getting updated so the client would read a garbage time. We chased NTP for a week before realizing it was the kernel.

Making an assumption that a day 86400 seconds breaks at least twice a year in many parts of the world, and that's before we introduce leap seconds or possibility of your code running on hardware that itself travels across timezones.

>We convert timestamps to and from date+times all the time.

If you do not account for time zones during this conversion, then you are not qualified to implement such conversions.

It's fine to use 86400 seconds for durations (e.g. "this computation will finish in 1d 8h 20m 34s"), but it's absolutely not fine to use it while dealing with datetimes.

[0]: https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_futu...

Unless there's a leap second in that month. Then it would be 13:59. Maybe you don't care, but some people do. It could have legal or technical ramifications.

> Now, if I cannot really add a month anymore (and I cannot in TAI, because months don't even really exist in TAI, since TAI isn't a solar year).

What do you mean by month? Calendar months are obviously irregular (thanks February). "30 days" makes perfect sense in TAI. Indeed, 14:00 today + 30 days would always be 14:00 in TAI.

> In 2021, it was reported that Earth was spinning faster in 2020 and experienced the 28 shortest days since 1960, each of which lasted less than 86399.999 seconds.[24] This caused engineers worldwide to discuss a negative leap second and other possible timekeeping measures, some of which could eliminate leap seconds.[25] The shortest day ever recorded was 29 June 2022, at 1.59 milliseconds less than 24 hours.[26] In a 2024 paper published in Nature, Duncan Agnew of the Scripps Institution of Oceanography projects that the water from increasing ice cap melting will migrate to the equator and thus cause the rate of rotation to slow down again.[26]

I'd argue the opposite is true for anyone who has studied statistics which is largely built on Instrumentalism (think George Box: 'All models are wrong, but some are useful') and Popperian falsification (Null Hypothesis testing). We are absolutely taught to treat models as predictive tools rather than metaphysical truths.

I can see how someone could misunderstand or forget what they're taught though.

Thanks for making me a decade younger :)

For 99% of the world today, high noon =/= 12:00:00. Nothing breaks because of this. The world continues to run.

Before modern standardization, maintaining calendars and clocks was typically the responsibility of states or similar authorities, often guided by astronomers. Now it seems that international organizations are effectively following the early UNIX/POSIX model, and astronomers no longer have the same authority over timekeeping.

Compare that to removing the leap day, where the start of seasons would be noticeably affected within just a few decades. Hundreds of years ago, a pretty insignificant headache was invented which is providing constant payoffs.

Statistically, nobody on Earth knows what UTC is. People know about their local time zone and how it related to time zones in other countries. Where the position of the sun is relative to UTC, almost nobody knows.

How can people manage with noon off by minutes, yet want leap-second accuracy every 6 months?

Most of the world is perfectly fine with 12:00 not being synchronized with high noon [0]. And some jurisdictions still semiannually f*k with it further using DST. Generously assuming the current time keeping system will survive for ~6k years (looking at the leap seconds accumulation rate for the last 50 years) we can just shift timezones by one hour.

[0]: https://64.media.tumblr.com/4a9a4613f057d3b5f17ec548e6ac06d1...

Do you know how long that is on a civilizational scale? When we try to develop warnings for nuclear waste storage that will last that long it’s mostly impossible because we assume there will be absolutely no civilizational continuity/shared context.

Doing 20k years of regular maintenance just in case we somehow keep using the same timekeeping system is completely unhinged. Better to jump an hour in 6k years if people in 6k years decide they care.

6,000 years ago is 1,000 years before Stonehenge.

And this isn’t about whether we use the same calendar, we’re talking about whether we have time keeping continuity down to the second. This requires infrastructure continuity and essentially no adjustments whatsoever over that time.

On unix this is what CLOCK_MONOTONIC is for; for one thing, the real-time clock can be reset at any time. Technically even CLOCK_MONOTONIC could jump forward. Real-time embedded systems either provide other timing APIs, or make additional guarantees about CLOCK_MONOTONIC's behavior.

The FreeBSD folks test(ed?) their code for these things and it works:

* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...

Of course third-party userland code understanding what happens is another thing.