I have a nerdy interest in all things timekeeping and calendar, so I’ve been following with interest the news that the International Bureau of Weights and Measures, which is in charge of the UTC system, is meeting this week to decide whether to keep the leap second. Under the scheme as it currently stands, a leap second (leading to a 61 second minute) is occasionally inserted on 30 June or 31 December to take into account the Earths’s (slightly irregular) rotation; without this leap second, UTC would drift away from mean solar time at Greenwich. These leap seconds occur irregularly and are inserted whenever needed, but apparently they wreak havoc on IT systems, which has given rise to demands to ditch them and give up the synchronicity between UTC and GMT.
Interesting. I didn’t know there was a significant unpredictable component to the change of the Earth’s orbital-rotational relationship. What causes this? The interior density of both the Earth and the Moon is variable (some bits denser than others) – mascoms and the like – and, for Earth anyway, some of these denser bits are always slowly moving (in the liquid part of the mantle). Is this the cause – either by itself, or because it perturbs the gravitational relationship between Earth and Moon? Or is it something else?
According to these scientists from NASA’s JPL, it’s a result of shifts in the distribution of water and ice (and hence mass) on the Earth’s surface:
Cool - thanks. GRACE was a mission whose spacecraft seemed like from a sci-fi movie: two monoliths locked into a gravitational dance.
Reading your link, it’s amazing how anthropogenic climate change is an important factor in changes in the direction and magnitude of these wobbles, and how drought near 45 degrees latitude (e.g., in parts of India) have a bigger effect than ice melting near the poles.
Even water impounded in reservoirs created by human-built dams has a measurable effect on the Earth’s rotation.
And yes, the leap second has been a nightmare for computer timekeeping. Every time a new leap second is announced, every damn computer in the world, including embedded systems with no internet access, needs to be updated. I’ll be happy to see it go.
What kinds of systems need that level of time synchronization but keep time internally rather than using an external time synchronization service? It seems like time drift would be an issue in those types of components regardless of whether leap seconds are used or not.
I see there have been only 27 leap seconds since 1971. It seems to me we could wait another 50 years and just have a leap minute. Would cause a lot less disruption. And, in 50 years, we might very well have come up ways to deal with the disruption much better.
(apologies if this was covered in the links. I didn’t read the actual articles.)
Internal time synchronization is the standard within distributed systems, mostly so they can determine the order of events coming from different machines. It’s going to be an issue for a network of pretty much any size.
Of course, time drift and out-of-synch machines is a known problem, so programmers already deal with this. The unique problem of the leap second is that it happens so rarely, it doesn’t really get tested and you end up with unanticipated events never seen in normal operation.
We have real-world examples of the problems it can cause. In past leap second additions, Reddit, LinkedIn, Qantas Airlines, and other systems have gone down.
This blog post gets into some of the details of one cause. Basically, applications and services typically go into an idle state when they are waiting for some other service to complete an action. The module that wakes them up went haywire when a leap second was added and woke up everything, pegging the CPU and leading to huge performance drops or complete system crashes.
There’s now the threat of a negative leap second being necessary due to an increase in Earth’s rotational speed. Computer systems in general can handle an extra second better than a missing second, so no one knows what chaos that could create.
The latest plan is to let the discrepancy grow to an hour before doing anything about it, which would likely push this out for a few thousand years. A few years ago, they were discussing letting it go until 2135. That seems a better approach to me - at least reevaluate in 100 years based on the size of the offset versus the impact and difficulty of any changes given the state of software architecture at the time.
Why not have computer systems ignore the leap second at the moment it occurs, and then let their usual time-correction system bring them back into synchronization?
That is fine for a single machine, but it doesn’t work for distributed systems that need to know the order of database writes from different machines, for example. That synchronization doesn’t happen across all machines uniformly at the same time.
Check out the article I linked above - it doesn’t describe every challenge, but it mentions a few and does a decent job of explaining a very technical subject at a (mostly) layman level.
also earthquakes … I recall back in 2010 when we had the big 8.something and parts of Chile got up to 4m wider - and this also threw the rotational axle off by some minor, but non-zero degree.
Those are some serious shifts in weight, compared to a dam
I stumbled over an article in Spanish about this leap second. Lots of details I ignored, some have been mentioned in this thread already, but in case someone is interested:
I found it interesting that substracting a second could cause more problems than adding a second, and that Google adds a second “diluting” it in the course of a day, while others do it in one go. The comment section, unfortunately, is atrocious.
If a computer system cannot handle a leap second, that system is buggy and badly implemented. It has nothing to do with international standards, but with whatever programmer erroneously assumed UTC is some kind of monotonic time measure or otherwise not adjustable backwards and forwards. That is what atomic time is for.
It’s also interesting how political positions lie on this issue. According to this CNN article, Russia favours retaining the leap second because its Glonass satellite navigation systems incorporates it. The UK has, historically, also supported the leap second because of the prominence it gives to Greenwich Mean Time as a benchmark, but has lately changed its stance.
Is there some kind of conspiracy theory behind this, like some corporations do not like leap seconds for some reason? The reason they exist is because the wall-clock time is supposed to have something to do with the Sun and time of day, and it is trivial (and necessary, and what actually happens) for a computer to convert between displayed time and its internal clock.
For instance, in Linux a program can ask for the number of nanoseconds since a particular instant and do whatever it wants with that (figure out UTC, for example), and in case someone adjusts the time or something (not talking about leap seconds) there is another facility that is guaranteed to tick forward at a constant rate regardless of whether the user resets the clock.
NB for various purposes, currently UTC is kept within 0.9s of Universal Time, but I do not know off the top of my head if anything bad would happen if the difference were, say, −2.3 s.
Distributed systems need to use “vector clocks”, anyway.
AIUI, the original reason for keeping UTC in sync with GMT was for celestial navigation - you’d want the sky to look exactly the way it’s meant to look at the time indicated on your clock if you’re using celestial observations to determine your position. I suppose there’s not much navigation of this sort going on these days (although it is, AFAIK, still taught in nautical training), and even to the extent there is, I suppose this could be easily handled by means of publicity announced conversion scalars.
I am well aware of this application (I do not know if manual celestial navigation is still being taught to mariners, however), and the Almanac already does warn you to convert UTC time to Universal Time for high precision, and also includes a simple correction table (which currently only goes to 0.9s, of course).
Yes, a system should use a monotonic time standard internally, but if it needs to use UTC for anything (display perhaps), it needs a table of leap seconds that needs to be manually updated whenever a new leap second is added.