Comment by michaelt
4 days ago
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.
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!
Well that's just pure insanity. I have to know this now. I didn't need this :D
A leap smear for a leap-second insertion needs to run the clock slower, not faster.