

Leap seconds exist because the Earth takes (very roughly) about a millisecond more than 24 * 60 * 60 seconds to rotate each day; when we have accumulated enough extra milliseconds, a leap second is inserted into UTC to keep it in sync with the Earth. At the moment the Earth is rotating faster than in recent decades: these shorter days, with a lower length-of-day, means the milliseconds accumulate more slowly, and we get fewer leap seconds. [...]
Michael Deckers said in his LEAPSECS message that we haven't seen a rate difference as low as zero since 1961! This implies that unless something wild happens, we are very unlikely to have a leap second in the next few years. [...]
The absence of leap seconds has the advantage that leap second bugs don't get tickled, but it has the disadvantage that timekeeping code might rot and new bugs or regressions can be introduced without anyone noticing. Even worse is the risk of the length of day getting shorter which could in theory mean we might need a negative leap second. There has never been a negative leap second, and if there is one, everyone who deals with NTP or kernel timekeeping code expects that it will be an appalling shitshow.
Clearly the best, most proactive solution here is to arrange for something very, very large to hit the Earth while traveling West.
Someone please explain to me how a running process tells the difference between a negative leap second and (being swapped out|being transported from one VM hardware to another), getting back to execution and finding "Oh, look, it's one second later than I thought, I must have been asleep."
I do not think a negative leap second is a problem.
Also, the last time earth was spinning this fast was during World War 2. The year 1961 is an artifact of when BIH began to tabulate its atomic time scale, so all time before then is less precise than after, and BIH did not produce tabulations for before then. Other measurements did (see website URL).
Assuming that the counter only goes in one direction might lead you to write systems which use unsigned integers for time deltas, say hundreds of times per second in performance-monitoring code or security's integrity checking. If your clock goes backwards, those ints wrap (at best) and unpredictable behaviour follows.
The s__tshow might be mitigated by the Google-type leap-second-smearing. Might be.
K3n.
The clock jumping backward would be a positive leap second, which we have seen cause problems before. A negative leap second looks like the clock jumping forward. Please try again to describe how that causes trouble to running software.
(We take it as given that systems with physical components in motion will have problems either way, which is why the precision time folks who were involved with the inception for leap seconds in 1970 all said their systems would use TAI-like time scales without leap seconds.)
When you're using past info to compare to current info, or expecting a sequence. Did you process any transactions in the last second ? Did you process fewer than expected in the last minute ? Did you iterate 60 times over what is now only 59 elements ? Are you running a process until the 'next' element doesn't exist, which you think means you've run out of new data ? You may have special-cased some of these things to not be confused by the extra leap second in UTC, but going from 23:59:58 to 00:00 (or 00:00:00 to 00:00:02, I've no idea where they'd actually action it) probably won't be gracefully handled.
I am still not seeing how purely software examples are different than time-sharing, swapping, VM transfers, communications dropouts, etc. In contrast with experiencing a chunk of time twice, I think missing the experience of a chunk of time is rather routine for pure software systems.
You make a good case that the micro-comas processes experience in a VM environment are indistinguishable from negative leap seconds. So any code migrated to a VM has likely already been exposed to this scenario.
However not everything had been migrated to VMs. Code that runs on little microcontrollers under real-time OS for example. And then there’s the components of a VM’s hypervisor too.
Microcontrollers are proliferating at an accelerated pace these days and popping up in places you might not expect. IoT is a big driver of course. They also show up in closed systems. For example even something as simple as the switch that would flip when you open a car door to deliver power to the dome light has been replaced with a much more complex yet more reliable part. Now instead of a simple mechanical SPST switch, it is a little 8 bit microcontroller listening to a Hall effect sensor. When it detects the door open, it sends a “turn on” message down the network to the dome light which also is driven by a little microcontroller.
In 1970 the folks involved in the decision process published a report saying that leap seconds would cause trouble for navigation systems, and one author who was head at USNO announced that OMEGA, TRANSIT, LORAN-C would not use leap seconds, but rather a TAI-like time scale. GPS system time employs the same TAI-like notion. Other navigation satellite systems do likewise. The Advanced Television Systems Committee chose that for digital TV. All of those systems dependent on precision times saw that first report which said "Doctor it hurts when I do this" and they avoided the trouble that leap seconds cause.
While TAI has the attractive property of continuity, it has the unattractive property of being out of sync with civil timekeeping. For presentation to humans, TAI needs to be converted to UTC at the whims of celestial objects, and then to local time at the whims of politicians and business.
It would be a dumb television that said it was 22:00:37 when News at Ten starts. It would be an even dumber person who used a TAI alarm clock, keeping to the diurnal cycle of 1960 while everyone else lives in $CURRENT_YEAR
To answer your hypothetical at the top of the thread, a program could monitor the realtime vs monotonic/boottime clock? A negative leap second applied by NTP would change the delta between the two, while suspending the process would not. I think you could also detect discontinuities in monotonic/boottime clocks when moving VMs, which is why Linux 5.6 introduced time namespaces.
Yes, UTC is legal because it keeps close match with calendar days that are based on counting the number of times the sun goes around the sky. There are nations which are not ready to approve a calendar based purely on SI seconds.
The reason we have UTC with leap seconds is because of legal concerns. The radio broadcasts of old UTC with 86400 elastic seconds were deemed illegal by Germany, and with no time to think about the deeper implications the committees desperately raced to come up with something that could be legally used in all countries. Most of the delegates dared not represent purely atomic time as legal in their country without actions by lawmakers, but in that rush they could agree that the radio broadcast time signals funded by many nations could acceptably use leap seconds. The delegates whose systems used precise time then went back home and announced that the internal time scales of their systems would not use the new UTC.
TAI is not the legal time of any country, but look closer. The interface document for GPS says its system time is based on UTC(USNO); TAI is not mentioned anywhere in the document. In almost every country the legal time is UTC, and the national metrology agencies are tasked to keep legal time. For legal purposes TAI does not exist because it is not maintained by any national agency. The lingo of the documents for precise time systems has evolved to give the legal fiction priority over technical reality. UTC is the primary, and TAI is not a thing.
(Phone; excuse brevity)
That is... not how leap seconds work. Some minutes have 61 seconds, and in those minutes, time ticks like:
xx:yy:58
xx:yy:59
xx:yy:60
xx:(yy+1):00
Presumably in the case of a negative leap second, the clock will go from :58 to :00? I'd bet there's going to be some code, somewhere that looks a bit like "if this message is timestamped more than a second ago, discard it", and that'll likely cause problems.
The Earth is desperately trying to shake off these damn parasitic humans that keep infecting her. It's their fault the planet is so filthy that even the moon doesn't want to be around it anymore.
Maybe fear of the negative leap second shitshow will prompt people to finally stop messing with the epoch?
....Hah hah, no.
I'll settle for everyone who writes for The Epoch Times suddenly finding themselves out of jobs.
I've occasionally pondered if you could change the Earth's rotational rate by, say, strapping a bunch of horizontal Saturn V's at equal points along the equator.
Might be easier than trying to fix negative leap second bugs.
No. "The Core" was not a documentary, and you can't nuke a hurricane.
So uh, tell me again about your rocket?
"Pinky, are you pondering what I'm pondering?"
"Yes, Brain, but it would take all of humankind 's efforts for 1,000 years to produce that much rocket fuel. In the meantime, we would have had to fix the time code's bugs anyway."
The rockets would just put energy into the atmosphere. If you want to rocket propel the earth the engines need to be attached to the ground but with the nozzles in space, which is technologically problematic.
Easier is just to make everyone move uphill/toward the equator, only allow coal to be burned at a higher altitude than it is mined, pin glaciers to keep them from moving, etc.
Didn't occur to me until just now but you could probably slow down the earth and be energy neutral by having a ring train that moves material from closer to the pole to farther away but downhill.
"We have "top men" working on it."
"Like who?"
"Top. Men."
"Clearly the best, most proactive solution here is to arrange for something very, very large to hit the Earth while traveling West."
So, like the British Invasion or LSD?
Also, pure speculation but I wonder if changes in ice and ocean circulation are shifting mass towards the equator? In other words: negative leap seconds as an esoteric but serious consequence of global heating.
Interesting, but I would expect ocean mass etc. moving to the equator would slow the earth down. Que demo of spinning ice skater moving their arms out.
You're right of course (I was thinking backwards) but there is evidence that heating related changes in ocean circulations are putting more mass closer to the poles, apparently:
Earth Spun Faster in 2009 Due to Ocean Current?
Perhaps this?
