BIPM decides to stop adding leap seconds to UTC
bipm.orgIn the very far future, leap seconds would become inadequate anyway, as you’d have to insert them every month, then every week, then every day, due to the deceleration of Earth’s rotation.
Leap seconds never did me any harm but DST is a constant menace, adding complexity everywhere.
Agreed on DST too, both are cases of a small harm done at a such a massive scale that the cumulative damage is significant.
Sure, you could also run a relativistic simulation of the solar system, galaxy, and cosmos to establish a more monotonic clock and calendar independent of imperfect orbital parameters, but that's a bit much for discerning whether or not it's lunchtime.
Barycentric Coordinate Time: https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time
The leapsecond corrections are to keep an imaginary "mean" solar time in place. But this mean solar time is almost unphysical-- and not observable except through very fancy astronomy.
If you are actually interested in getting an accurate solar/astronomical time leapseconds are something of a hindrance, as you need to back them out to apply formula corrections and there isn't a general way to know if a recent leap second has actually been applied to your timebase (or double applied, or smeared or a spurious one applied...).
Which doesn't seem like that is soon, but time/calendar issues can creep up and then it's a big hullabaloo:
People have a hard time with leap years, which happen regularly every four years, so I'm curious to know how well a "one-off" event at a basically random time in the future will work.
Worrying about a couple of seconds or even minutes is completely insane for almost everyone.
This makes getting a fairly accurate solar time arguably easier, in fact, because you can use a formula correction on top of a stable timebase without first backing out leapseconds which may or may not have been correctly applied.
The page lists several good reasons for this, including:
- It's a common source of bugs.
- Solar time is not that important in a world of coarse timezones.
- IoT and anything that cannot receive time updates have trouble with leap seconds.
- Negative leap seconds have never occurred before, but might occur in the future, and almost no software has tested this case.
I'd also add:
- Unix timestamps are actually defined as "seconds since epoch minus however many leap seconds have happened". It's a hack to keep code that assumes "86400 seconds in a day" from breaking. It means that during a leap second the Unix timestamp goes back and repeats a previous value, making them ambiguous and non-monotonic.
- Leap second unpredictability can make it impossible to calculate how many seconds are between two UTC dates or Unix timestamps, for example the countdown to the year 2038 bug.
- The proper ISO8601 formatting of leap seconds ("23:59:60") is widely unsupported, breaking parsers, along with the assumption of how many seconds are in a minute, hour, or day.
---
EDIT: I've emailed hn@ycombinator.com to change the title. It's avoiding editorialization, but I think it's also preventing the post from getting the attention it deserves.
I'm booking a yearly one-second-long holiday on my calendar, to celebrate all the headaches this will save me. Happy end of leap seconds!
I don’t see that reason listed on the page, and future wall-clock times remain unpredictable due to changes in time zone rules.
What will become predictable is the relationship between posix time and elapsed time (in the sense of TAI), at least within the next few hundred years.
So the exact duration between any two times would be easily computed, so long as those times were precise enough to include their timezone-- which they have to be already.
So while the political time zones don't change retroactively, the technical rules used in computers can.
@-tags like this don't do anything, you're better off sending an email. I think hn@ycombinator.com is the address.
FreeBSD tests stuff like this for the code that they take care of:
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
Third-party stuff (like from Ports) is another question.
On a side note, I really like how the site formatted the reasoning. I'll be copying it to my technical writing.
From now on UTC will in practice be TAI but with a constant offset (=all previous leap seconds).
So the example given Feb-31 is stored as 1 month + 30 days past the start of the year and would trigger right on time march 2nd or 3rd, depending on leap year. In fact I started doing it to handle birthdays on leap day, there is not always a February 29, but there is always a day 29 days after the start of February.
No, an easy option is to simply shift every timezone by an hour and keep UTC intact. A ton of places already do that twice a year for daylight savings.
I never understood why we mess with UTC so much when we already have another widely used mechanism to keep the sun and clocks aligned.
And maybe we should stop touching political timezones by then anyways.
But given the amount of time it is going to take to accumulate so much as another leap minute's worth of leap time, let alone an hour, I'm pretty confident we're in the "arrogant" branch if we start declaring what they need.
P(nobody cares about UTC anymore anyhow | someone had to solve the problem of incorporating non-terrestrial time which is way harder than leap seconds) would seem to me to approach 100%. You can decide which branch you want to take, but P(things just keep on keeping on without much change from today for the next several thousand years) seems not large enough to start trying to make lots of plans for.
Random local government people declare it is to be, and ... as an industry we largely figure it out.
The more responsible governments give amble notice and as an industry we are very very good at that (you not realizing it, is an example).
And good riddance to leap seconds! It was too hard for us to figure out, and they didn't do anything useful for anyone.
... of course you're talking about events that would be approximately 4000 years from now!
And it's not that we wouldn't have a time without leap seconds. Instead of changing the time definition it would make much more sense to switch to TAI for me. Now we will have tons of UTC code hanging around with support for leap seconds that will never be used and if you want to remove it you will have to distinguish between old and new UTC. Not a fan.
"A minute has 60 seconds" is simple.
"A minute has 59, 60, or 61 seconds. Consult CGPM publications or your national timekeeping authority to find out." is not simple at all.
Almost every programming language and database I've ever used assumes 86400-second days, ignoring leap seconds. And one of the popular ways of applying leap seconds was a 'smear' [1] running every clock slightly fast for about 24 hours, rather than having a 61-second minute.
So instead of UTC we actually all use a slightly elastic timescale with the name of UTC, most of the time aligned with UTC, but with the linearity of TAI, and the desirable property that if I'm going to a concert at 19:00 in a year's time and a leapsecond is announced and implemented in the interim, the concert doesn't change to 18:59:59.
Edit...scratch that, now I have to keep track of UT1-UTC as a separately continuously varying parameter provided by IERS instead of tzdata
In the open seas, celestial navigation is more than accurate enough. Once you are closer to shore, where the greater precision is needed, better options exists. Lights, ranges, radar, visual, etc.
This is unfair.
If AI wants to be a coder then it has to do leap seconds. In fact, let's give it leap minutes and leap hours too.
Hopefully by the time UTC drifts more than an hour from UT1, we’ll be a spacefaring civilization that is happy to treat time as wholly independent from how a particular rock moves.
We in fact have high confidence that it’s not true. Google started leap smearing back in 2008 because so much broke on leap seconds.
Honestly I’d think a negative leap second would have way higher chances of just working than positive: a positive leap second causes a minute to have a 61st second, and a unix timestamp to repeat. That is a highly rare condition and plays complete havoc on software which does not specifically support these.
A negative leap just means jumping a second, this is already relatively routine due to scheduling and suspends, your program can do one thing and then 20 minutes occur before the next, because right then the user closed their laptop lid.
I guess we'll be seeing more and more idiocratic offloading of current problems onto the future generations, contrary to the premise that AI will solve all of them.