It's interesting to think about the ramifications of decoupling our measurement of time from the earth's position in the solar system. For example, when we read that something happened around 11 AM, we know that it's probably daylight time, but if we allow for drift, then we can't make that assumption anymore for certain timescales. If the error is small, we can probably deal with it the same way most people understand that dollars in 1950 don't have the same value as dollars today.
Unless you're within a few feet of the longitude of the center of the timezone, this is already the case.
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.
> That ship sailed, back in the railroad era when we decided to standardize time away from mean solar time.
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.
I chose the wording “maybe a half hour or 45 minutes” to make it crystal-clear that the exact number was not relevant to the argument, in a vain effort to avoid responses like this one. Perhaps I should be more explicitly vague in the future. HN is tiring.
No, you’re absolutely right. As someone who uses UTC professionally in aerospace ops, trust me when I say your clock is still definitely tied to solar time even if it’s “off” by whatever. Try using UTC exclusively—I don’t just mean on your servers, I mean in every single aspect of your life—and you’ll see what I mean.
Yeah, I'm musing abotu the possibility of using monotonic time. Right now, our time system conveys implicit information about the "solar time of day" (whether or not its daylight in the locale) as well as season (January is winter in the Northern Hemisphere). For monotonic time, you would have to use some sort of conversion function to recoup that information. As we both noted, certain monotonic time systems could be used which deviate very little from solar time such that the accumulated error would only make a difference (for the purpose of recouping that aforementioned implicit information) at very large time scales, which is a problem we already face with inflation (1950s dollars are not the same value as 2021 dollars and we all seem to manage alright with that).
A negative leap second would suppress second 23:59:59 of the last day of a chosen month so that second 23:59:58 of that date would be followed immediately by second 00:00:00 of the following date. Since the introduction of leap seconds, the mean solar day has outpaced atomic time only for very brief periods and has not triggered a negative leap second.
A removed leap-second is gobs easier to handle. I can't say if it will or won't be handled properly, because I never tested it, but roughly you have three options:
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
The GHG/snow angle is really smart. I initially thought that petroleum extraction/carbon emissions would slow the planet ever so slightly because we're taking stuff from underground and moving it into the atmosphere. But water/ice are much heavier, and reducing the range of elevations where snow is trapped would do the opposite (less water at higher elevations and more at lower), plus there's way more snow/water than petroleum.
If it is validated perhaps advocates for change will be able to make the argument that we are literally running out of time and it will prove sufficiently engaging that 'skeptics' lose traction in trying and failing to refute it. I use scare quotes because many self-styled climate skeptics are not sincere inquirers after truth but rather shills for established economic interests.
Petroleum and gasses should be lighter than the rock surrounding them right, so if you move those up, the rock above those layers will be moved closer to the earth's center. So I would expect that that will cause the earth to spin faster, not slower.
That's a good point, so it could be both. I'm not sure how high the average distribution of CO2 would have to be to offset that. The petroleum/gas could also be compressed under pressure, which might offset that effect to some degree.
Back of the envelope calculation: a 1 ms/day slowing would require ~10^20 kg of mass at the equator to be moved a km inward. For scale, wiki helpfully points out that the world's oceans weighs 10^21 kg.
I love the idea of switching to atomic time. Using a different paradigm to conceptualize it could lead all sorts of whimsical new approaches to representing it, and where whimsy wanders new insights and discoveries often ensue.
On the one hand I agree. On the other hand the discrepancy to solar time is growing quadratically due to tidal friction of the earth with the moon, which is prone to create interesting issues some centuries down the line.
The projections I've seen estimate that the drift would reach about 1 hour in a millenia (i.e. around year 3000), ± few centuries. And I don't even know if 1 hour difference really would be that significant, these days already some regions have their local time differ from solar time by over an hour (e.g. Argentina, Spain, large parts of China) because of timezone shenanigans.
It's weird to talk about "switching" to atomic time. If you want seconds to always go 58,59,0, and you want time to always increment 1 second at a time, then UTC has never been appropriate. People who need to measure time this way should already be using TAI or GPS Time (which do this). Many people already do this, there's no "switching" needed.
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.
> It's weird to talk about "switching" to atomic time.
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.
It's difficult to answer how many seconds are between two times because whether there was a leap second or not is not the result of an algorithm. Leap seconds are added to keep time synchronized to the rotation of the earth (i.e. so noon is when the sun is at its apex).
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.
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 :-).
Nice insight on how new systems can lead to apparently unrelated discoveries!
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
I don't think a negative leap second would cause much of an issue at all. The reason a positive leap second was such a problem was because it add an "invalid entry", ie. 23:59:60.
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.
> I don't think a negative leap second would cause much of an issue at all.
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.
> Every time your computer does an NTP update and has to jump ahead one second
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.
I was talking about ntpd. It would do its update after the negative leap second and then think to itself "oh, I'm more than one second behind now, I better start fuzzing and catch up".
It's rare for ntpd to step time forward, unless ntpd lost synchronization and the local clock has drifted beyond +/- 128 ms by default. On a 7x24 production server, it's very unlikely, time is always slewed. But a standard leap second implementation requires the addition or deletion of time via adjtimex()'s TIME_INS and TIME_DEL, it's not adjusted gradually.
> "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?
Does NTP do that, though? I was under the impression it made time slightly faster/slower until the point is met, if the difference is small (which it will always be on production servers, in principle)
ntpd does indeed skip time, contrary to popular belief. I didn't believe it myself until one day I studied the documentation and code.
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.
Yes, but the documentation is wrong in its assumption. There are many reasons time may skew >128ms beyond "network congestion."
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...
a skip ahead is different than the officially being at 23:59:60, albeit quite many NTP nowaday use leap smearing to avoid that https://developers.google.com/time/smear
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.
Great, at least we know the kernel is probably good (assuming Linux gets tested too and at least the latest version doesn't have bugs)... But I still worry about the interactions in a complex userspace application can produce unexpected outcomes. And I wonder whether Linux previously had bugs (too lazy to trace down the git history today), and if there was, how many are still in deployment...
What I don’t understand is what the world gains by this level of global software time accuracy that couldn’t be localized to the very specialized cases that actually need it. Why can’t the world generally drift a second here and there over a few years and super time sensitive programs keep a tally of leap seconds to adjust? Sure it’s a pain in the ass for those applications, but isn’t “we don’t know for sure if this time adjustment is going to disrupt major world affairs” more of one?
> The reason a positive leap second was such a problem was because it add an "invalid entry", ie. 23:59:60.
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.
> You'll encounter the same problem if 23:59:58 is followed by 00:00:00
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.
That's not really the type of "skipping" that is the issue.
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.
A negative leap second, unaccounted for, would cause anything scheduled during that second to be skipped. Probably not Y2K catastrophic, but certainly could be a problem.
I would expect global warming to have the opposite effect. Slightly expanding the atmosphere causing the mass to be further from the center, slowing down the rotation.
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.
I have a different idea, it could be the global warming. A lot of snow and ice melt and flow down from the mountains in to the ocean. So a lot of mass does come a bit closer to the center and would it make it more fast.
And wasn't lately not also something with the magnetic field?
Basically yes. They're saying snow melting is a big cause, because it brings that heavy water weight down closer, along with erosion and the mountains bringing dirt down closer to the center.
The environment of and around the earth is pretty chaotic. Think it is way to soon to postulate what caused such a tiny variation. How to account for it, different subject.
Odd that I read this first a few days ago via a link to a Martha Steward website lol
If the average mass of the earth moves from high to low elevation then the rotation of the earth will increase in order to preserve angular momentum. It's the same physics as an ice skater who spins faster when they move their arms close to their body.
That's one reason. Another reason could be that the Earth is not symmetric and the Moon is pulling it in some strange way. Or perhaps some people have installed lots of flywheel energy storage units [1] somewhere, all spinning in one direction.
> 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).
Atomoc clocks are nuts accurate nowadays. They’re so good you can measure the relativistic gravitational time dilation effect of a height difference of a few inches. It takes a while, like about a year I think, but you can do it.
People talk about rockets and computers, but to me atomic clocks are the pinnacle of human achievement. So many other technologies are built off of accurate time measurement, and it's a very clever mechanism (at least the one in Boulder is that I'm aware of).
The semiconductor is pretty good, too, but not nearly as clever.
BTW, after seeing some "spiritual" comments on Facebook inspired by the news, I posted this:
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:
Or, possibly, it stays the same without variation and the measurement was flawed. A recent study indicates our most accurate clock may not be infallible[1].
I'm not sure why computer scientists really care. Call me a naysayer if you like: but why can't we just ignore this problem?
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.
Yes. The only ones who will notice the difference are the astronomers, who created the problem in the first place (unless the time-difference becomes so big that it starts affecting perceived daylight times).
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.
I wonder how we define a "day" and when do decide it is next day now. Earth rotates/wiggles all the time and it is far from a perfect sphere or any shape. And it changes its shape as well
How can we decide on such small time scales it is no longer the same day when there are so many variables.
96 comments
[ 3.6 ms ] story [ 165 ms ] threadThat 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.
https://en.wikipedia.org/wiki/Leap_second#Process
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
https://www.wolframalpha.com/input/?i=rotational+angular+mom...
https://en.wikipedia.org/wiki/Orders_of_magnitude_(mass)#101...
[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!
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.
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.
Odd that I read this first a few days ago via a link to a Martha Steward website lol
"Mwahahahaha! It works, it works!"
His assistant types onto their tablet... Test of MegaRaptor Engine successful.
[1] https://en.wikipedia.org/wiki/Flywheel_energy_storage
I've commented about going downhill in unrelated messages where the vast majority is not trying to move anything but up.
> 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:
https://www.ucolick.org/~sla/leapsecs/dutc.html
P.S. gravity isn't constant either[2].
[1]- https://www.nature.com/articles/s41467-020-18264-4
[2]- https://en.wikipedia.org/wiki/Gravity_anomaly
What is it about the Earth's rotation that draws all the crackpot "theorists"?
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.
Can anyone speak to the problems regarding "true time?"