The Earth has been spinning faster lately
phys.org
phys.org
> Scientists also noted that this past summer, on July 19, the shortest day ever was recorded—it was 1.4602 milliseconds shorter than the standard.
It’s so interesting to think about (a) how incredibly stable the rotation of the earth in in human terms, and also (b) how far we’ve come to be able to measure something so vast (the rotation of our planet) against a scale so tiny (milliseconds - shorter than an blink).
The world is amazing :)
The semiconductor is pretty good, too, but not nearly as clever.
It changes all the time, the variations are small, the real long term trend is actually for the rotation to slow down, we are not now at a historic extreme. The talks about the leap second are due to cumulative deviations over a few decades, which are normal. The reporting is not factually wrong, but it's limited. Check the LOD (length of day) graphs on the Lick Observatory site:
P.S. gravity isn't constant either[2].
What is it about the Earth's rotation that draws all the crackpot "theorists"?
But a negative leap second would just be skipping a valid entry, which happens all the time if you're using NTP to set your clock.
Sure, date math libraries would need to updated, but they already got updated for the positive leap second to have tables they can look up to find out which seconds to add, so adding an entry for a skip isn't much different.
Most of the havoc of the positive leap second was in time series data having that invalid entry. That won't happen with a negative leap second. There just won't be a value there.
But nobody has tested it in the wild. It's entirely possible to trigger an existing bug in the code base. I expect some disruption from the first negative leap second event. After that everything would probably be gradually stabilized.
PCs don't run anything crucial, usually you can set your clock to 2001 without visible problems, the same is not true for a server. A server uses ntpd, not a bruce-force ntpdate. Under ordinary conditions, ntpd adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. But I think a negative leap second is quite violent.
> "oh, I'm more than one second behind now, I better start fuzzing and catch up".
No, ntpd would say, oh, leap second, now it's the time to tell kernel to delete a second! And if the kernel's negative leap second code path has a bug, kernel panics and everything crashes.
...Yes, you probably can force ntpd to ignore the leap second deletion and also force NTP to slew time only. This approach is similar to leap second smearing (which is considered a violation of standard but nevertheless an useful hack). But it requires manual configuration, by default the standard approach is used.
So the bottom-line is: Time will be forcefully stepped ahead by 1 second (which is an uncommon scenario on production server), and, it would not just be an ordinary step - it uses the operating systems normally untested negative leap second code path. I'm not sure what the consequences would be for various services, perhaps not much, but my worry is the interactions in a complex application can produce unexpected outcomes. Also, how many systems have implemented the negative leap second in the code path? And are they all tested?
This is why the 2005 leap second crashed every Linux 2.4 kernel worldwide as I recall.
Thankfully there's been a push toward leap smear (certainly on every system I run) which should obviate this type of problem entirely.
Check out the "-x" flag in the manpage.
I recommend dumping ntpd and using chrony instead, and also configuring chrony for a time smear rather than the leap second as required by the standard.
The documentation also indicates it's rare for a 7x24 running server to suddenly step time (it only occurs when there's a 128 ms difference), unless you get serious network congestion that prevents sychroninization for an extended period, so a time step in a production server is uncommon. But a standard-compliant negative leap second requires time stepping, it's why I said there might be disruption.
I've dealt with datacenters getting a bad ntp config push, for example, or a bad firewall ruleset which blocks NTP. Fixing the config may inadvertantly step time.
There's a whole host of systems issues, sometimes involving VMs and sometimes bare metal which can cause this type of problem. The most simple of which is ntpd not running properly for a while, but this can also happen when systems get overloaded - extreme swapping and the like.
ntpd's behavior of non-monotonic time adjustments was brought to my attention after a developer uncovered database corruption, caused by a database which (correctly) assumed that time should be monotonically adjusted while the database server was running. I believe it mis-ordered a transaction log or something along those lines.
There are other, better ntpd implementations like chrony which can be configured to never step time. If time needs to be stepped, applications should be stopped and the machine should be removed from service first.
> There are other, better ntpd implementations like chrony which can be configured to never step time.
I totally agree that ntpd is worse, it has an aging code base with many potential security issues, chrony is a better and cleaner implementation. Nevertheless, I refuse to refer to "ntpd" as a worse implementation because it implemented the leap-second as the standard specified. Also, ntpd can be manually configured to never slew time (excluding leap second) if -x and -g are used.
> ntpd's behavior of non-monotonic time adjustments was brought to my attention after a developer uncovered database corruption.
BTW, my original topic here is how a negative leap second may cause service disruption, ntpd's behavior is only a footnote to that discussion. I think your experience only strengthened my original argument: if the standard leap second implementation (instead of smearing) is used, which is the case in a default configuration, something might happen. But I'm not sure, a negative leap second doesn't break the monotonic assumption. So it's all speculations...
The FreeBSD (kernel) folks test their code for it:
> I run the freebsd kernel and ntpd through "negative" leap second events usually a couple times a year as part of testing our timekeeping products at $work. I'm skeptical that we'll ever see a negative leap, but we have some customers who insist on having it demonstrated to them as working correctly.
> […]
* https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove...
Of course then there's userland…
It's only a problem if you have a hardcoded assumption that all minutes have exactly 60 seconds. You'll encounter the same problem if 23:59:58 is followed by 00:00:00
Computers don't usually count time in this manner and the display is converted via mathematical formula. It'd just have to be adjusted to account for leap seconds, positive or negative.
On the contrary, I would expect skipping a second to happen all the time from the perspective of userland programs, due to common things such as blocking system calls and program scheduling under load. Also features such as sleep and hibernate can easily skip entire days.
Software tends to ask the system the current time (via a library), and the system responds with a "here is a number, it is the number of [units] since [epoch]". The library then converts that number using a formula to work out a date/time. If it is decided a leap second is added or subtracted, and the library's formula doesn't account for it, then the time will be calculated incorrectly.
For most software it is unlikely to matter too much, but this sort of thing can lead to unpredictable emergent behavior in complex networked systems.
[0] https://medium.com/@duspom/proposal-for-a-base-10-calendar-b...
I don't think that's how productivity works
However, most civilian applications want a time that is synchronized, to bounded degree, to the Earth's rotation. UTC has leap seconds, which are occasionally added or removed, to make that happen.
There's been a push for removing leap seconds from UTC, because that'd be convenient for computers. But no one's figured out how to change the Earth's speed to match this new definition of UTC :-). So if we want time-of-day to be related to the position of the sun in the sky, adjustments like leap seconds are necessary.
The biggest reason to describe it as "switching from UTC to TAI" (at least for me) is due to Unix time. Unix time is an elegant concept at first glance, ideally it's a free-running, monotonic counter that abstracts us away from timezone problems, an unambiguous representation of time. You only adjust the timezone settings or the timezone database, the time itself is never adjusted.
Unfortunately, using UTC rather than TAI as Unix time's foundation is a fatal mistake. As Unix time cannot represent leap seconds, all the previous advantages break down - we had to freeze or advance the Unix time itself to compensate for that limitation. If there's a TAI-based "new Unix time", the leap second handling can be simplified a lot. The underlying time is always correct regardless of leap seconds. Sure, a missed leap second notification makes all civilian time faster or slower by 1 second, but the situation is the same for UTC if there's no time synchronization.
Why has it never been appropriate?
You're better with something like epoch time because the duration between two times is always the absolute value of their subtraction. You don't have to store a chart to figure out whether the difference in wall time between 3:03:03 and 03:03:05 is 2 seconds or if there was a leap second and it should be 3 seconds.
You can do it, but you have to check the behavior of all your libraries. Which isn't fun. And make sure that somebody doesn't do an optimization that switches the behavior at some point.
Because UTC has never worked that way.
UTC is an international standard for a "time of day" standard where every second is exactly one second long and is boundedly synchronized to the rotation of the Earth. But the Earth wobbles. The UTC solution is to occasionally add or remove leap seconds, so sometimes you see 58, 59, 60, 0, and we might someday see 58,0.
People complain that "leap seconds are hard" but there's a reason for them. Here are your options:
* If you want to always have 58,59,0, and you don't really care that time always increments exactly 1 second per second, then you can keep the time synchronized with Earth's rotation by smearing the time or having the time "jump" a little bit around leap seconds. This is what actually happens in many Unix systems. When we get near a leap second, the "seconds" are briefly not quite correct. It's a bounded error of a second or less and doesn't accumulate. For most people this error is just fine, which is why Unix time works for most people.
* If you want to always have 58,59,0, and you DO really care that time increments exactly 1 second per second, then don't keep the "time of day" the time synchronized with Earth's rotation. That's what TAI and GPS time do. But most people feel that ordinary civilian "time of day" should have some relationship to the position of the sun in the sky, which is why this is not the normal civilian "time of day" value.
* If you want to always have 58,59,0, AND you want time increments of exactly 1 second per second, AND you want time synchronized with Earth's rotation, then you need to regulate the Earth's actual rotational speed. I'm not sure how anyone would do that, but I suspect that will be very expensive :-).
I'd like to see not only switching to atomic time, but also to UTC globally, which would be far more convenient, but also may have it's own set of interesting minor discoveries
2. Summarising why I agree with 1.): With UTC (or whatever other time zone you'd standardise on), you "know" what time it is everywhere (because it's the same everywhere), but if you actually want to know what that means for people elsewhere (i.e. are they likely working/sleeping/eating/...), you'd still have to look it up, just like you need to look up time zones today.
At the same time though, because time loses its relation to the solar day, any mention of time you read or hear about in some article/piece of news/story/novel/... a) becomes completely meaningless without being tied to a concrete geographic location and b) if it's elsewhere, remains meaningless without looking up which bit of the solar day that time actually corresponds to at that location.
3. At the price of creating the International Date Line, the current system has the very useful property that the local calendar date changes at a time when most people are asleep or otherwise don't really care about it. With a single global time zone on the other hand, no matter what meridian you choose, 00:00 will happen right in the middle of the waking hours of a significant fraction of the planet. Having the calendar date change in the middle of the calendar is incredibly confusing and would necessitate using unwieldy double dates ("today is the 14th/15th") to make things unambiguous again. Public holidays and suchlike would have to be specified with starting and ending hours instead of being able to rely on the sensible default of midnight local time (and doing so would effectively reintroduce some sort of time zones through the back door, which calendar software would have to be able to handle, too – unless you want to force half of the world having their holidays starting and ending during typical waking hours)
Right now this is only a common problem when having to coordinate things with people in significantly differing time zones, but under your proposal, those unlucky people that are not living near the meridian will have to deal with it constantly when dealing with their local time (which for most people will be much more frequently that having to schedule a meeting with someone on the opposite site of the planet).
Arg 2, not knowing what reports meant - this would probably require saying something like "At 01:00UTC, early morning in Sydney Australia, Gov. Smith declared...".
However, the date issue might be more of a problem creator, as, I'm right now about 21:40 on the US East Coast, but it is already about 2:40 UTC, so my date would have changed about an hour ago. so, yes, less convenient until we get used to it.
Tho, when I work past midnight, it is kind of a 'so what'?
And, I literally had a meeting screwed up today because of time zones - and the guy I met with has to deal with China, India, EU, and US time zones - it's make his life a LOT easier.
Also as more people move off earth and work in orbit, on the moon, etc., and we need to communicate with them. What works best
Definitely requires more thought. Thanks!
https://www.wolframalpha.com/input/?i=rotational+angular+mom...
https://en.wikipedia.org/wiki/Orders_of_magnitude_(mass)#101...
That ship sailed, back in the railroad era when we decided to standardize time away from mean solar time.
If we assume that the Gregorian calendar remains in use for as long as it's already been in use, the total accumulated error would likely be on the order of minutes. We could use a monotonic time scale like TAI for literally centuries and nobody would notice except astronomers, and arguably it would simplify astronomical corrections too because the underlying scale would be monotonic, which it isn't presently.
I’ll make the case here that we still use mean solar time, we just quantize it and push it around for political reasons. In any case, using time zones just means that your clock is off by maybe a half hour or 45 minutes in the lower US, and given the natural variation for sunrise and sunset, that doesn’t seem like an outrageous amount of error for temperate latitudes.
Granted, there are a few places in the world with larger differences, like Spain or western China, or Argentina for some reason.
Changes in the period of the Earth’s rotation have been estimated based on records of eclipses from as far back as the 8th century, which show that the Earth’s rotational speed is slowing down. Trying to extrapolate from fifty years of atomic time is going to give you the “on the order of minutes” estimate which is likely wrong. If you are trying to work out the error over five centuries, you should probably be using the best available data, which is records of eclipses and ephemerides.
a) software ignores it, and your clock is a second behind as of the discontinuity, and adjusts eventually
b) software handles it properly and jumps ahead
c) software handles it by explicitly dithering the difference over a day
d) c, but it also jumps ahead at the discontinuity
e) your network has a mix of b, c, and d, resulting in wonky clocks throughout the day, but generally still +/- 1 second of real time. This could be problematic for forensics, or for distributed software that uses time as measured on nodes to determine order of operations, but using time as measured on nodes requires constant vigilence to ensure clocks are in sync enough.
An added leap second is a lot trickier because at least Linux and FreeBSD simply repeat the last second of the minute at the discontinuity if you don't take special action to dither it. That brings two new problems:
a) real time is no longer monotonic
b) a logic error can result in repeating that second forever
Time as we think of it in computers is an overlay over time in the physical world. If they're off by a millisecond will anyone notice?
I was a high frequency trader for a long time. The only thing that matters in time world is that computers agree on the same time. Not that computer time is aligned with real world time.
On the other hand, it would be great if some authority could release a package with time conversion routines that everybody could include in their software projects and be done with it. However, every language needs its own implementation, which is a problem created/not fixed by IT people.
How can we decide on such small time scales it is no longer the same day when there are so many variables.
Odd that I read this first a few days ago via a link to a Martha Steward website lol
Heavier material in the mantle subsiding towards the core could do it just as easily, and there is a lot more mass beneath the crust than above it.
The problem is that the atmosphere is so light compared to the rest of the earth that even at the nanosecond level I have doubts you would see this effect. To affect the rotation of the Earth by whole seconds/year you need to be talking about yottatons of rock shifting.
And wasn't lately not also something with the magnetic field?
> They also have begun wondering if global warming might push the Earth to spin faster as the snow caps and high-altitude snows begin disappearing.
Can anyone speak to the problems regarding "true time?"
I've commented about going downhill in unrelated messages where the vast majority is not trying to move anything but up.
"Mwahahahaha! It works, it works!"
His assistant types onto their tablet... Test of MegaRaptor Engine successful.