Comment by weinzierl
3 days ago
Reading all these reasons sounds like defeat to me. It is sad that in 2026 we cannot even pull off a simple thing like adding or removing a second rarely and long announced to one of our time definitions.
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.
IMO it's not a simple thing, even at a surface level.
"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.
For thousands of years, we used time synchronized to the sun, with flexible intervals. That’s the natural thing for a lot of things, and that is what UTC is for.
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.
For thousands of years, we used time synchronized to the sun to some approximation that was off by minutes, not microseconds, and nobody cared if the current time relative to the sun was off by a second because they had no way of actually determining that. And then some jerk came along and invented computers and precision timekeeping and suddenly things depended on things like time not appearing to move backwards by as much as a second. :)
UTC is still fixed to the sun. Without leap seconds, it will be hundreds of years before the divergence between UTC and the sun is perceptible in daily life. Even then, I can't think of anything where that would matter.
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."
6 replies →
We have GMT for standardised solar time. I assume there were good reasons for moving to UTC? Either is fine for many purposes.
3 replies →
More importantly, in the second case the definition is not static so implementations will inevitably disagree which makes things an even bigger mess.
As I understand it, almost nobody was actually using UTC anyway.
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.
[1] https://developers.google.com/time/smear
I have yet to see a single clock able to show 23:59:60. Not just computers, any clock at all
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
I believe one of the alarm clocks I have owned around the turn of the century could display 23:59:60 and understood leap seconds.
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.
It's very rare. I wrote my own clock application to properly see the leap second back in 2015. Here is a recording: https://fedorapeople.org/~mlichvar/leap2015/clock_step.gif
I used to have an oven whose clock would display 23:60 before jumping to 00:01!
1 reply →
A leap smear for a leap-second insertion needs to run the clock slower, not faster.
> Reading all these reasons sounds like defeat to me.
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.
I also see this as a defeat. BIPM's Bulletin C announcing the leap second or lack thereof, is almost always very close to full six months before the event. Even this is almost enough time to both develop and test an implementation, not just test it, plus there are usually years of no action between the events.
> 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.