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

111–120 of 159 posts

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

#111

Post by deepsun »

theamk wrote: post #96
fuoqi wrote: post #95

Computer systems (most importantly, UNIX) should've been using TAI [0] from the beginning. Human-readable time in turn should be computed from it using periodically updated time zones database which would include offset between TAI and UTC. By eliminating leap seconds we effectively re-invented TAI with a weird offset. While I am in favor of eliminating leap seconds as a hacky way to fix the current mess, it's sad to…

No, they should not. We convert timestamps to and from date+times all the time. Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that. Leap second smearing will ensure smooth and continious time. Taking leap seconds into account is only needed in a very, very few contexts - maybe astronomy, or certain kinds of high-speed physics? Those rare users should be able t…

Your message contradicts itself. Firstly it says leap seconds should not be used (aka TAI). But at the last sentence it says "go with UTC" (which has leap seconds).

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

#112

Post by al_borland »

sarchertech wrote: post #99

The idea that if being dark at 12pm in 20k years will bother anyone is absurd. The shift will happen so slowly that the only people who will even realize it happened are historians and history buffs. Really the idea that there will enough civilizational continuity that our current timekeeping infrastructure and systems will continue unbroken for that long is insane.

Changing a global time system is not a trivial task.

We’re still using a calendar developed over 400 years ago and just making minor tweaks. Without some central global authority, change is unlikely. And even with that, it would be extraordinary disruptive.

The middle for the day, on our time keeping devices, being light outside goes all the way back to the first sundials over 3,000 years ago.

Small and regular maintenance is more realistic than expecting a complete overhaul of timekeeping at some point when are lack of maintenance becomes so problematic that the whole system needs to be thrown away.

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

#113

Post by Ozzie_osman »

The worst bug I ever dealt with in a 20 year career was a leap second bug (back in 2012). Servers all slowed down dramatically very suddenly, CPU saturated. No relevant code changes or changes in traffic. Turns out, they just got into that state due to a leap second. Some Livelock bug.

A restart fixed everything.

It wasn't just our site that went down. If I recall correctly, many other large sites (like Reddit, LinkedIn, etc) also had the same issue. Guess no one thought of the "did you try restarting it?"

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

#115

Post by rausr »

Ozzie_osman wrote: post #113

The worst bug I ever dealt with in a 20 year career was a leap second bug (back in 2012). Servers all slowed down dramatically very suddenly, CPU saturated. No relevant code changes or changes in traffic. Turns out, they just got into that state due to a leap second. Some Livelock bug. A restart fixed everything. It wasn't just our site that went down. If I recall correctly, many other large sites (like Reddit, Linke…

I remember that well (because my manager at the time was asking me afterwards "why were you up at 2 in the morning restarting services?" and didn't believe my answer :( )

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

#116

Post by al_borland »

Vvector wrote: post #40
coldpie wrote: post #14

Earlier quoted context omitted.

Hmm. I understand that perspective, but I'm not sure I agree. It does seem to matter over a relatively short & realistic time scale. According to the Wikipedia page, there have been 27 seconds added since 1972, which is only 44 years ago. At that rate, that's about 1 minute per 100 years. We have many systems that have existed for several centuries and I think it's not unreasonable to start making plans for systems t…

Can you explain how a 10 minute offset would affect you in any way? For 99% of the world today, high noon =/= 12:00:00. Nothing breaks because of this. The world continues to run.

I ran into this trying to view the meridian line at the Basilica of Saint Mary of the Angels in Rome.

I was told the sun would show up on the calendar in the floor at noon. As noon approached, I saw nothing. Then I figured it probably needed to be solar noon, so had to look that up and wait around until that time. Today, that will be 12:20pm.

Nothing would have broken had I missed this, and nothing of critical importance is running on a solar clock (I don’t think), but it still led to a discrepancy in what was expected and where I needed to be when, based on drift from solar noon.

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

#117

Post by darkwater »

Ozzie_osman wrote: post #113

The worst bug I ever dealt with in a 20 year career was a leap second bug (back in 2012). Servers all slowed down dramatically very suddenly, CPU saturated. No relevant code changes or changes in traffic. Turns out, they just got into that state due to a leap second. Some Livelock bug. A restart fixed everything. It wasn't just our site that went down. If I recall correctly, many other large sites (like Reddit, Linke…

Yep, I was there too! HN thread from the time: https://news.ycombinator.com/item?id=4188412

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

#118

Post by darkwater »

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

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

You mean 09226, I believe. [1]

[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

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

#119

Post by klausa »

deepsun wrote: post #110
klausa wrote: post #106

Earlier quoted context omitted.

>Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that. 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.

Timezones have nothing to do with UTC or unix time. Timezones only come into play when you convert between to other timezones.

Sure; but I happen to be one of the dozens of people who do not live in UTC.

So you have to do the conversion at some point _anyway_.

If your app presents me data making the assumption that _my_ day is always 86400s, it will be _wrong_.

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

#120

Post by leni536 »

5-0 wrote: post #105
leni536 wrote: post #71

Earlier quoted context omitted.

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 handle…

WDYM? Leap seconds are a 61st second, hitting 60 before 00 next minute. https://nrc.canada.ca/en/certifications-evaluations-standard... This makes sense for timestamps in traditional logs. You don't have to second guess the order of things, especially across multiple systems or services.

I meant unix and NTP times, which are supposedly just monotonic numbers marching forward (except for leap seconds), not the UTC representation over abstract time.

I know we just get a 60th second in a minute. What unix and NTP timestamps do (or originally did) was repeating a second. Then we got other hacks to keep monotonicity, like smearing. Not without tradeoffs.

Post reply on HN