Live data from Hacker News

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

lists.iana.org

91–100 of 159 posts

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

#91
post #68

Earlier quoted context omitted.

They teach us Scientific Realism in school, but reality is that we are really using Instrumentalism. That said, no one wants to admit it, so contemporary science follows Falsification, where we find ways to not actually make claims about reality. (Which as an Instrumentalist/pragmatist, I love Karl Popper, its just not metaphysical truth. And that would break Popper's heart)

No they do not teach Scientific Realism in schools. We're taught the scientific method and then build upon that. I can see how someone could misunderstand or forget what they're taught though.

K12 teachers arent educated enough to realize the words they use imply scientific realism.

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

#93

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, fo…

[deleted]

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

#94

Google and lots of other firms use a "leap smear" to hide the leap second from end users, essentially "smearing" the second across the hours before and after each leap. https://developers.google.com/time/smear

https://xkcd.com/2266

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

#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 see that we added yet another quirk to the already complicated system of datetime keeping.

[0]: https://en.wikipedia.org/wiki/International_Atomic_Time

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

#96
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 to figure stuff out.

Go with UTC, don't optimize for rare usecases at the expense of everyone else.

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

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

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

#100
post #96
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…

You clearly do not know how much havoc and complexity leap seconds introduce into various systems. This is why leap seconds are likely to be phased-out [0]. It's effectively an admission that use of leap seconds in the "base" time was a mistake.

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

Post reply on HN