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.
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!
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.
Agreed.
I never really understood the big issue with these. Systems need to be flexible enough to compensate for clock drift between devices already. On cheap devices like IOT devices (called out in this memo for their lack of capabilities) clocks diverge _all the time_ because cheap timing crystals aren’t great.
Even on expensive desktop PCs, audio and video hardware clocks diverge enough that compensation is required just to watch a YouTube video with the audio synchronized with video all the way to the end, and that’s without Bluetooth devices and the like inserting even more clocks into the system.
If our systems can’t cope with smearing a leap second in either direction every now and then, something is wrong.
> Instead of changing the time definition it would make much more sense to switch to TAI for me.
Should UTC permanently stop diverging from TAI, it is more likely that the opposite would happen - TAI would be subsumed by UTC, because there would be no need to maintain two timescales.
Systems which prefer not to deal with discontinuities already use TAI. Many packet capture / timestamping systems natively operate in TAI, and UTC conversion is/can be done in "post-processing". Many / most time servers also do internally, and for example the native time scale for IEEE 1588 / Precision Time Protocol is TAI, and UTC->TAI offset and leap events are announced separately. NTP though, while using its own epoch, is still UTC aligned and while it indicates the LS events, it operates on discontinuous timestamps.
TL;DR: Time sync hard; must make easy.
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.
... of course you're talking about events that would be approximately 4000 years from now!
On a side note, I really like how the site formatted the reasoning. I'll be copying it to my technical writing.
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.
Could you make an example application where it could be an issue? I imagine it would have to be an appliance that needs high precision time, is not connected to the internet, and hence it has an internal clock that is accurate over long times.
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.
That's a pretty big smear if you want to convert an existing clock from one to the other.
But because the sun's trajectory changes throughout the year, and we live in very coarse timezones already, it was always a bit useless tracking this with seconds precision.
@-tags like this don't do anything, you're better off sending an email. I think hn@ycombinator.com is the address.
From now on UTC will in practice be TAI but with a constant offset (=all previous leap seconds).
This part I simply fail to understand. In the age of CI and formalised approach to testing? What about, simply, "good engineering practices"? What, we look at a (defined, described, standardised) corner case and go "naaah, how likely is that...", and just let it slide? What, if we have a 64-bit counter somewhere, do we go "how likely is that to roll over..."? I f# hope we don't.
In any case, I don't accept the "hasn't been tested" argument. Those mechanisms have been in place for decades now, so what if we had no occurrence. I think this is helpful FUD and buzz generated to accelerate moving away from a slightly cumbersome maintenance event, and I get it, but the "not tested" to me, is (or should be!) an insult to software and hardware engineers out there.
As someone involved in time sync and always on alert during leap seconds (leap second party anyone?), I have mixed feelings here. On the one hand this is less work, but on the other, it is a triumph of reducing complexity - or laziness, dare I say - over "correctness".
The can kicking (inventing a "leap hour" we will almost certainly never use) is what this resolution was about, the decision that leap seconds were a bad idea pre-dates this significantly. Leap hours were always a likely candidate for the can kicking exercise, but I believe there were other possibilities.
Imo, the best solution is to just keep every time/date format eternally backwards compatible. And if you do need a change, whether that's leap seconds or daylights saving changes or whatnot: just create a new format
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.
Long overdue. Sad they didn't realize this in 1972 and avoid all the silliness in between.
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.
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.
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 UTC 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.
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.
Which doesn't seem like that is soon, but time/calendar issues can creep up and then it's a big hullabaloo:
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.
In 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.
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...).
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.
Barycentric Coordinate Time: https://en.wikipedia.org/wiki/Barycentric_Coordinate_Time
There is no issue that didn’t already exist, but it remains true that future wall-clock times cannot be predicted with certainty, because tzdata may change between now and the future time.
When someone sets an alarm for 12:00 in five years in the current time zone, how do you store that? It can make a difference whether you store it as a Unix timestamp or as broken-down time plus time zone.
So while the political time zones don't change retroactively, the technical rules used in computers can.
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.
The solar noon never happens at 12:00 anywhere anymore. We've left that era about 200 years ago when we synched clocks with the capital city for the benefit of train schedules.
P.S. Well, technically the solar noon happens at 12:00 in New York on January 2nd, Chicago on Jan 14, Denver on Dec 25th, Los Angeles on Jan 9, etc. (on other dates, it's off.) In Santiago de Compostela — where they want to be on the same clock as Warsaw — solar noon happens as "early" as 13:18 and as late as 14:40.
If so I'm failing to see how this is less likely to cause bugs
Coming from someone whose daily work has been time sync for years (me):
If you look at Linux and many other Unix and Unix-like systems, to me it's the insertion of a leap second that has more potential for a failure than a removal.
Insertion ("positive leap seconds"): Time formatting functions will output "hh:mm:60" - this in itself is bound to catch some sofware off-guard - but internally during an insertion the same epoch value runs twice: 123456789.999999999 -> 123456789.000000000, which again is bound to cause some amount of confusion to assorted systems, and clearly the smear was implemented to combat this.
Surely this must be worse than the removal ("negative leap seconds"): 123456789.999999999 -> 123456790.000000000 - yes, still a discontinuity, but we have continuous increase and no ":60".
During my time spent developing time sync architectures and software, I tested both, ad nauseam, and tested it for others, a lot, GNSS simulators and all. Clearly precision time sync remains a specialised discipline, and pays my bills, so I don't mind, but I think this is a case of FUD combined with poor engineering practice and inadequate software testing eventually defeating a well-established timekeeping practice that (now this is more poetical than factual) allowed us to keep our timekeeping aligned with "nature".
I actually think we're in for a bigger mess when after this resolution we attempt to big-bang a batch update, but I will be retired and actually more likely dead and gone by the time this happens, so...
And maybe we should stop touching political timezones by then anyways.
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.
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.
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.
Nobody has a real UT1 clock†, some observation sites prepare guesses at UT1 mostly in terms of how far it deviates from TAI because you can just buy clocks that keep TAI really well.
† You could say this damp rock, "The Earth" is such a clock, and I guess I reluctantly accept that argument but then OK the UI for that clock is abysmal, nobody can use this the way you'd use an actual clock unless they accept miserably bad precision.
Every system seems to either 1) jump back/forward, 2) smear, 3) ignore it because a drift of more than one second is already accepted in that system
However that's a radio alarm clock which also knows the exact date-time, including year - one of the best presents I have ever received from friends who saw it and realised oh, that is exactly what tialaramex needs. In the smartphone era I do not need one.
Now, if you don’t care about the sun but about fixed intervals, you can always use TAI.
Standards are there to serve people, and we should have the choice to use the standard that fits our needs best. Changing the meaning of a standard retroactively, with no good reason and when a good alternative is available, is nothing short of irresponsible.
I think there is a good alternative available, UT1. UTC was always divergent from UT1 anyway, so this change shouldn't affect anyone who actually needs precise solar timekeeping.
More importantly, there are many good reasons to drop leap seconds, such as the massive increase in complexity they impose on all time-related code.
Standards should serve people, which is why leap seconds should never have existed. Imagine: "Sure some airliners crashed, and half the internet went offline for a couple days, but if you drive to the right longitude line, the sun will be exactly overhead at 12:00:00, and here in town it's overhead at 12:23:48. That's worth anything. I'd hate to live in a world where it was overhead at 12:23:49, or that'd be over my great-great-great grandchildren at 12:23:47."
The problems with letting dUT1 > 1800 and above is that well before that it starts mattering for almost everything and then you have to consult the solution (here's just 2025's):
https://crf.usno.navy.mil/quarterly-vlbi-solution
GMT (Grenwich Mean Time) is a legacy from when Britain (and thus Grenwich, an observatory in London, England) was more important. These days GMT, even in British legislation, just means UTC. When we say "In the winter we use GMT not BST" we're not switching to or from some archaic time system, GMT is just defined as UTC+0 and BST is defined as UTC+1 the same way summer time zones work in several others places which have them.
And it has, the bound on the deviation was increased slightly to 3600 seconds
I'm just highlighting that in most places when it says "GMT" it does not mean solar time, just like how "New Street Station" in Birmingham is not in fact a New Station, or on a New Street, it's a station which was close enough to the road in Birmingham named "New Street" that it's forever associated.
When actual Grenwich Mean Time was "still a thing" astronomers would use it for solar time because we had no better approximations. Today the IERS looks at very distant objects in the sky. We know that in some sense (relative to us) these are not moving because they're incredibly far away, and so we can use them to measure rotation. And then we adjust for where the Sun is from that data.