Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lists.iana.org

Post reply on HN
Print view View original

71–80 of 159 posts

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

#71

Post by leni536 »

imglorp wrote: post #56
dijit wrote: post #43

Earlier quoted context omitted.

Just here to reinforce your point. The last leap-second I encountered (also the 2014 one) crashed my MySQL databases. you wouldn't assume that it depends on time like that, because honestly why would it? "surely it's fine, NTP corrects drift of a second fairly frequently"- but a leap second is not a drift, it's something quite insane unless your primitives are solid. Nobody would test for this.

Yes I would assume that the NTP daemon would handle a leap second arrival with guarantees of (1) gradual application over a longer period and (2) never moving the clock backwards, only slowing it a little. 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…

The insanity is that both NTP and unix timestamps need to be wound back during a leap second, as well as computer hardware clocks. If we just had monotonic clocks everwhere and adjusted for leap seconds in presentation then we wouldn't have many of the associated problems.

It's not like we wound back by 24 hours on leap days, that would be insanity. So in addition of leapseconds being a rare problem, it's also handled in a uniquely bad way.

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

#72

Post by fanf2 »

michaelt wrote: post #62
throw0101d wrote: post #7

Earlier quoted context omitted.

> The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely. There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such. One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation…

> One 'answer' to this concern is to have a 'leap hour' or something in the future 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

Yeah. There’s also the issue that the earth’s rotation is slowing down, so over the long term leap seconds would become more and more frequent. There’s a point when the earth is slow enough that leap seconds need to happen nearly every month, and by that point they are no longer a workable solution to the problem. That is expected to take a few thousand years, comparable to the point where a leap hour would be needed if there were no leap seconds.

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

#73

Post by xg15 »

toast0 wrote: post #22
SeanDav wrote: post #10

I assumed that leap seconds could be determined algorithmically, it appears I assumed badly. This is a bit of a can of worms...

They basically are, the algorithm is something like: At the beginning of january and july, observe the difference between UT1 and UTC. If the difference is >= 0.6s, a leap second will be inserted at the end of june/december. Publish the results here: https://hpiers.obspm.fr/eoppc/bul/bulc

Waiting until Trump discovers that the earth rotation service exists and forces them to insert a negative leap second just because he can.

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

#74

Post by clickety_clack »

throw0101d wrote: post #7
imglorp wrote: post #4

Responding to a deleted comment: > ... the "invisible infrastructure" of the web; balancing historical accuracy with the technical need to minimize zone fragmentation is a much more complex trade-off than it appears on the surface ... The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely. At $wo…

> The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely. There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such. One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation…

In British Colombia they’re locking into daylight savings time, so I think it’s safe to say that people aren’t really bothered by solar accuracy.

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

#75

Post by recursivecaveat »

throw0101d wrote: post #38
zamadatix wrote: post #32

Earlier quoted context omitted.

Leap seconds have so many problems beyond the time adjustment. It's a small/odd enough adjustment interval that there are wildly different approaches like leap smears. On top of being so small, it's rare enough (~every 2 years), depending on how a system is used, lack of proper handling might not be obviously apparent or lack of obvious problem in one implementation ignoring it may lead to lack of care in another imp…

DST changes are pre-scheduled. Throwing a random hour in/out at (say) June 30, 2029 may be something else. Unless the jump is treated as a TZ change in tzdata ?

Yeah you treat it as a time zone change where every zone moves over (or every country moves to the adjacent zone maybe). You can schedule it N years in advance. It's definitely not 0 disruption, but it's very manageable. Regions change TZs or toggle DST frequently enough that we can handle it.

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

#76

Post by TurdF3rguson »

throw0101d wrote: post #7
imglorp wrote: post #4

Responding to a deleted comment: > ... the "invisible infrastructure" of the web; balancing historical accuracy with the technical need to minimize zone fragmentation is a much more complex trade-off than it appears on the surface ... The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely. At $wo…

> The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely. There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such. One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation…

>There is some talk of eliminating the leap second

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.

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

#77

Post by nstents »

TurdF3rguson wrote: post #76
throw0101d wrote: post #7

Earlier quoted context omitted.

> The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely. There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such. One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation…

>There is some talk of eliminating the leap second 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.

[dead]

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

#78

Post by SchemaLoad »

idiotsecant wrote: post #34

We should just have a standards body that meets each decade and decides what epoch time every day for the next 10 years officially starts on. Everyone knows ahead of time how it will work, software updates have predictable change intervals, it allows us to refresh time based on policy decisions, and it uses something sane as the backbone of the system.

Every 10 years is just the right frequency that most software breaks, but it causes frequent pain for everyone. Switching to leap hours that have to be dealt with every few thousand years would be much preferable.

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

#79

Post by jmusall »

xg15 wrote: post #73
toast0 wrote: post #22

Earlier quoted context omitted.

They basically are, the algorithm is something like: At the beginning of january and july, observe the difference between UT1 and UTC. If the difference is >= 0.6s, a leap second will be inserted at the end of june/december. Publish the results here: https://hpiers.obspm.fr/eoppc/bul/bulc

Waiting until Trump discovers that the earth rotation service exists and forces them to insert a negative leap second just because he can.

Then, when the stock market crashes due to software failures and timing inconsistencies, he'll want to undo it and thereby cause even more chaos ;)

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

#80

Post by anotherpaulg »

wlkr wrote: post #3

Interesting! There's a lot I don't know about this, but I know a little more now. I'll admit, I naively thought this would be more regular than it appears to be [0]. [0]: https://en.wikipedia.org/wiki/Leap_second

The Earth is generally expected to spin more slowly over time, due to tidal friction. But it has been spinning faster and faster since the 1960s. As shown in the figure in the wikipedia article [0].

I have read numerous explanations, but haven't found a really authoritative discussion.

[0] https://en.wikipedia.org/wiki/Leap_second#Rationale

Post reply on HN