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

81–90 of 159 posts

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

#81

Post by vilhelm_s »

xorcist wrote: post #16
Vvector wrote: post #13

Leap Seconds need to be abolished. The only people who need it are Astronomers. They could just use an offset. Implementing leap seconds correctly is a huge burden, for no gain. Where I live, high noon today occurs at 1:03 PM. No one is complaining that it is 3 minutes (or 63 minutes) off. It's a non-issue for 99.9% of the population.

Unless you want to abolish timezones entirely, which would simplify clocks but complicate a whole lot else in society, you're going to need leap- something . Would leap minutes or hours really be much better? The idea that doing things less often causes more problems is a reasonable one.

We need to do "leap hours" anyway--just today they changed to daylight saving time in the U.S.! And time zones are also adjusted every now and then, which also amounts to a one-hour change in the affected regions. Even if we didn't have continous practice with leap seconds, I think we could definitely include an extra one-hour shift for earth rotation reasons along with all the other ones.

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

#82

Post by wanhandle »

Back in the early 2010s my company was maintaining a Spring application processing ActiveMQ messages. We'd received word that the application wasn't processing work. One of us goes and looks at logs and sees just endless volumes of stack traces. Eventually the suggestion is made and accepted to just reboot the application. That fixed it.

Turns out the JVM simply lost its mind when leap seconds were introduced. So, for the next several years, we watched that French society's website that announced when leap seconds would be introduced and scheduled application restarts accordingly.

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

#83

Post by pinkmuffinere »

anotherpaulg wrote: post #80
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

Wow that's really interesting. A great quote form the article:

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

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

#84

Post by wahern »

netsharc wrote: post #8
throw0101d wrote: post #6

There was some talk about a negative leap second† a few years ago: * https://www.npr.org/2024/03/30/1241674216/climate-change-tim... † T23:59:58Z would have skipped/suppressed :59 and gone to T00:00:00Z.

You make it sound like time labels like "23:59:58Z" can perform actions (e.g. to skip or "suppress"). I had to look it up: https://www.timeanddate.com/time/negative-leap-second.html . In proper words, the clock ("the one humanity agrees to use) would skip 23:59:59Z. I wonder how much chaos a minute that only has 59 seconds would cause. Measurements would be off by that missing second (e.g. a pipeline delivering fuel…

Nobody should be using an API like time(2) or clock_gettime(2)+CLOCK_REALTIME to measure event durations with sub-second precision or accuracy, especially when controlling mechanical equipment. And I'd be absolutely surprised if anybody was when controlling equipment, at least in a regulated industry.

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.

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

#85

Post by treis »

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.

Oh thank God I thought I was going to make it through a thread on leap seconds without a political discussion

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

#86

Post by treis »

wahern wrote: post #84
netsharc wrote: post #8

Earlier quoted context omitted.

You make it sound like time labels like "23:59:58Z" can perform actions (e.g. to skip or "suppress"). I had to look it up: https://www.timeanddate.com/time/negative-leap-second.html . In proper words, the clock ("the one humanity agrees to use) would skip 23:59:59Z. I wonder how much chaos a minute that only has 59 seconds would cause. Measurements would be off by that missing second (e.g. a pipeline delivering fuel…

Nobody should be using an API like time(2) or clock_gettime(2)+CLOCK_REALTIME to measure event durations with sub-second precision or accuracy, especially when controlling mechanical equipment. And I'd be absolutely surprised if anybody was when controlling equipment, at least in a regulated industry. On unix this is what CLOCK_MONOTONIC is for; for one thing, the real-time clock can be reset at any time. Technically…

I feel like most of us don't know what we're actually doing when we do t2-t1 to get a duration. Feels like it'd be in a lot of places and a negative number is going to cause havoc. Even worse if it's an unsigned int and you roll over to some massive duration.

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

#87

Post by vmilner »

throwup238 wrote: post #65
michaelt wrote: post #62

Earlier quoted context omitted.

> 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

> The leap hour will be in 7200 years, around year 9226. 7200 years ago the Neolithic revolution was still in full swing and many of the most famous megaliths like Stonehenge hadn’t even been built yet. The first real state, the Sumerian civilization, hadn’t formed yet in Mesopotamia. Personally, I’m very comfortable making this someone else’s problems 7200 years from now. If they’re still having basic coordination i…

"And so the Y10K problem was born"

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

#88

Post by layer8 »

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

You're missing that the frequency of leap seconds is accelerating over time, because Earth's rotation is slowing down. The leap hour will therefore happen earlier: https://www.ucolick.org/~sla/leapsecs/future2100.svg

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

#89

Post by cesarb »

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…

> One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation's problem, not ours)

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.

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

#90

Post by IKnowComputer »

vmilner wrote: post #87
throwup238 wrote: post #65

Earlier quoted context omitted.

> The leap hour will be in 7200 years, around year 9226. 7200 years ago the Neolithic revolution was still in full swing and many of the most famous megaliths like Stonehenge hadn’t even been built yet. The first real state, the Sumerian civilization, hadn’t formed yet in Mesopotamia. Personally, I’m very comfortable making this someone else’s problems 7200 years from now. If they’re still having basic coordination i…

"And so the Y10K problem was born"

I’d better go brush up on my COBOL
Post reply on HN