[flagged]
No leap second will be introduced at the end of June 2026
101–110 of 159 posts
Re: No leap second will be introduced at the end of June 2026
#102[flagged]
You need therapy ASAP.
Re: No leap second will be introduced at the end of June 2026
#103Re: No leap second will be introduced at the end of June 2026
#104Earlier 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 just had a Y10K problem. Customer data was using 9999-12-31 23:59:59 as a placeholder value, and our app crashed converting from the customer's timezone to UTC. I learned that Python datetime can't handle Y10K.
Re: No leap second will be introduced at the end of June 2026
#105Earlier quoted context omitted.
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 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.
Re: No leap second will be introduced at the end of June 2026
#106Computer 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…
>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.
Re: No leap second will be introduced at the end of June 2026
#107Responding 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…
Yea, can't be arsed to do it right, so let's just not do it.
Re: No leap second will be introduced at the end of June 2026
#108Earlier 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
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…
So some future generations might get 23 hour days? That’s gonna be an interesting problem to solve for calendar implementations
Re: No leap second will be introduced at the end of June 2026
#109Earlier quoted context omitted.
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…
So some future generations might get 23 hour days? That’s gonna be an interesting problem to solve for calendar implementations
25-hour days.
Re: No leap second will be introduced at the end of June 2026
#110Earlier quoted context omitted.
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…
>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.