The Impact of Negative Leap Seconds: Risks and Challenges for IT Systems

  • Thread starter anorlunda
  • Start date
  • Tags
    Negative
In summary, the introduction of negative leap seconds is not much different than the introduction of positive leap seconds. Many or most IT systems probably have no provision for negative leap seconds and no testing for that event. Add to our list of time/date headaches; this one not Y2K related.
  • #1
anorlunda
Staff Emeritus
Insights Author
11,308
8,744
Conceptually, negative leap seconds are not much different than positive leap seconds. However, many or most IT systems probably have no provision for negative leap seconds and no testing for that event. Add to our list of time/date headaches; this one not Y2K related.
https://www.timeanddate.com/news/as...ne 29, Earth set,1.50 milliseconds on July 26.

1659439937704.png

If Earth’s fast rotation continues, it could lead to the introduction of the first-ever negative leap second.
What is causing the current downward trend in the length of the shortest day?

It could be related to processes in Earth’s inner or outer layers, oceans, tides, or even climate. Scientists are not sure, and struggle to make predictions about the length of day more than a year ahead. But there are tentative ideas.

At next week’s annual meeting of the Asia Oceania Geosciences Society (presentation SE05_A009), Leonid Zotov—together with his colleagues Christian Bizouard and Nikolay Sidorenkov—will suggest the current decrease in the length of day could have some relation to the ‘Chandler wobble’.
 
  • Like
  • Informative
Likes Filip Larsen, Wrichik Basu, russ_watters and 1 other person
Computer science news on Phys.org
  • #2
I am not a fan of leap seconds. So astronomical noon isn't the same as chronological noon? This is true for 3599/3600-ths of the planet ever since we set up Time Zones. Let it go for a couple millennia and we'll fix it when the next daylight savings time change comes around.

However, I don't see this as a problem. NTP can handle this, and most of our computers, whether we know it or not, get their time from NTP. They can even be a few seconds - or more - off when first connected to the network, and they quickly settled down.

If it is critically important that a computer keep time to better than a second, somebody is being paid to do so, and that person knows thge difference between UTC and UT1. (I don't, for sure)
 
  • #3
Time going backward can be a disaster on some computer systems. We had one example while drawing a time vs db level for various frequencies plot which looked similar to a stock price chart. One value had a bad time which caused a zig zag backward and then forward again.

Unable to fix the externally generated data, we tossed it when time went backwards relative to the previous value plotted. It was an intermittent problem so we didn't dwell on it even though we didn't like tossing data.
 
  • #4
Vanadium 50 said:
However, I don't see this as a problem.
I'm a fan of the school that says software that hasn't been tested doesn't work.

The problem is not figuring out what the time is. It is taking care of the consequences of minutes/hours/days with more or less than the standard number of seconds, and of skipping some intervals and doubling some intervals.

The problem is also dealing with bean counters. They take pride in tracking money down the the last penny. (Would you have it any other way?).

Then there are the impossible to predict logical problems, such as software that does stuff once per second, doing it a second time for the same second. (Whew, three meanings of second in the same sentence. o_O ) Leaps cause exactly the same kinds of problems we feared in Y2K. The size of the leap, seconds or years does not change the kinds of logical errors. If you want an example, think of a software safeguard that sends fraud alerts if it detects double billing. It takes real money and real labor to deal with petty annoyances.
 
  • #5
Lets not forget the leap rollover when the second counter exceeds the max unsigned value and rolls over to zero.
 
  • Haha
Likes phinds
  • #7
Bookmarked this one; it's got a number of implications for a number of "forbidden" topics.
 
  • #8
Bystander said:
Bookmarked this one; it's got a number of implications for a number of "forbidden" topics.
Huh? I don't get that.
 
  • #9
anorlunda said:
Huh? I don't get that.
GW is forbidden, is it not?
 
  • #10
Bystander said:
GW is forbidden, is it not?
Sorry, I must be slow tonight. What is GW?
 
  • #11
anorlunda said:
What is GW?
"Global Warming."
 
  • #12
anorlunda said:
I'm a fan of the school that says software that hasn't been tested doesn't work.
It is tested.

When you turn a Llinux - I have no idea what Windows does, other than that is surely confusing, overcomplicated and might not work very well) PC on after being shut off overnight, the real-time clock has drifted a few seconds off the real time. Sometimes ahead, sometimes behind. A few minutes (technically, a few times 64 seconds later) the system time syncs with NTP time. And as I said, sometimes this is forward and sometimes its back.

So this is not really new for "personal" computers.

Big iron? Well, 370's run Linux now, but other computers? Well, if you are running a zillion dollar enterprise and its critical that you don't ever, ever roll back, you probably should be using UT1 or a similar standard anyway. And paying someone who understands all the nuances to make sure this isn't a problem. For the rest of us, POSIX has a monotonic clock (which can take days to catch up if the clock is hours off). If someone needs it, the OS has it, and he doesn't use it, who is it on?
 
  • #14
By chance, I just encountered some press reports of real world examples.

https://engineering.fb.com/2022/07/...ts-time-to-leave-the-leap-second-in-the-past/
Back in 2012, Reddit experienced a massive outage because of a leap second; the site was inaccessible for 30 to 40 minutes. This happened when the time change confused the high-resolution timer (hrtimer), sparking hyperactivity on the servers, which locked up the machines’ CPUs.

In 2017, Cloudflare posted a very https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns/ about the impact of a leap second on the company’s public DNS. The root cause of the bug that affected their DNS service was the belief that time cannot go backward. The code took the upstream time values and fed them to Go’s rand.Int63n() function. The rand.Int63n() function promptly panicked because the argument was negative, which caused the DNS server to fail.

Leap second events have caused issues across the industry and continue to present many risks. As an industry, we bump into problems whenever a leap second is introduced. And because it’s such a rare event, it devastates the community every time it happens. With a growing demand for clock precision across all industries, the leap second is now causing more damage than good, resulting in disturbances and outages.

As engineers at Meta, we are supporting a larger community push to stop the future introduction of leap seconds and remain at the current level of 27, which we believe will be enough for the next millennium.

https://www.wired.com/2012/07/leap-second-glitch-explained/​

The Inside Story of the Extra Second That Crashed the Web​

The "leap second" crash -- which hit several web operations on Saturday evening -- can be traced to a single glitch in the Linux operating system. Here's the inside story on what happened.
 
  • Like
Likes pbuk
  • #15
anorlunda said:
By chance, I just encountered some press reports of real world examples.
Why do you think it is by chance?
 
  • #16
That was 2012. We've had two leap seconds since then. How did they go'?
 
  • #17
Badly: the Cloudflare one was 1 Jan 2017 (they must have got away with it 18 months before).
 
  • #18
  • #19
I meant why do you think it is by chance that you have just seen this rather than by observation by some AI of your recent reading interests?
 
  • #20
pbuk said:
I meant why do you think it is by chance that you have just seen this rather than by observation by some AI of your recent reading interests?
I'm not sure I understand the question.

  • The OP was triggered by the news of the first negative leap second. It showed up on my Google News Feed, which is not AI specific. Google first pointed me to a NY Post popular article.
  • I read the ACM Risks Forum as regularly as I read PF. It does not focus on AI, but rather on risks. That post in the risks forum came out August 1.
I see nothing other than a coincidence of timing of those two.
 
  • #21
After some more thought:

1. Leap seconds solves a non=problem. Who cares if the place where clock noon is the same as astronomical noon moves by 1500 feet?

2. Negative leap seconds solve even more of a non-problem, since there is an easy solution - wait. Do nothing for a year or three and

3, The present system confuses the difference between time labeling and time keeping. Time keeping is knowing that it is x seconds after a reference time. Time labeling tells us that x corresponds to March 17, 1995 at 5:21 exactly.

3, This suggests this is primarily a failure of analysis, not programming. Of course,m there can be bugs too, There can always be bugs.

Negative time adjustments can and are handled every single day, millions of times, without problems. I can understand a company not wanting to spend money on doing this right. But it's not an impossibility. The fact that this gets rediscovered, is disturbing.

4. Having this happen at any time other than the daylight/summer transitions is just asking for trouble.
 
  • #22
Vanadium 50 said:
1. Leap seconds solves a non=problem. Who cares if the place where clock noon is the same as astronomical noon moves by 1500 feet?
Indeed: I don't know anyone that understands the issues that thinks differently.

Vanadium 50 said:
2. Negative leap seconds solve even more of a non-problem, since there is an easy solution - wait. Do nothing for a year or three and
Probably, although as we are not sure why the Earth's rotation has speeded up we can't be sure it will slow down again.

Vanadium 50 said:
3, The present system confuses the difference between time labeling and time keeping. Time keeping is knowing that it is x seconds after a reference time. Time labeling tells us that x corresponds to March 17, 1995 at 5:21 exactly.
Agreed.

Vanadium 50 said:
3, This suggests this is primarily a failure of analysis, not programming. Of course,m there can be bugs too, There can always be bugs.
Kind of, although if you look at the history you can see how we got to where we are now with incrementally sensible analytical decisions. Or do you mean improper handling of leap seconds by current systems? I think this is a failure at every stage - the analyst should have specified how to handle negative time increments, the programmer should have worked out what to do with them and the tester should have tested it didn't catch fire.

Vanadium 50 said:
Negative time adjustments can and are handled every single day, millions of times, without problems. I can understand a company not wanting to spend money on doing this right. But it's not an impossibility. The fact that this gets rediscovered, is disturbing.
Agreed: Cloudflare in particular should not have got this wrong.

Vanadium 50 said:
4. Having this happen at any time other than the daylight/summer transitions is just asking for trouble.
:woot::wideeyed:o0):nb):biggrin::eek:o_O yeah, adjusting UTC at different times depending on the local transition time for daylight saving (if any) would be a lot of fun.
 
  • #23
Vanadium 50 said:
Who cares if the place where clock noon is the same as astronomical noon moves by 1500 feet?
GPS, among many other things. We are talking about leap seconds applied to Coordinated Universal Time upon which NTP and all other time standards are based. I can't imagine how many long term scientific experiments use UTC, and which may include the unstated assumption that time never moves backward. (Remember when CERN reported FTL neutrinos? That was not an IT error, but it illustrates sensitivity to elapsed times.)

Wikipedia says:
https://en.wikipedia.org/wiki/Coordinated_Universal_Time
The system has been adjusted several times, including a brief period during which the time-coordination radio signals broadcast both UTC and "Stepped Atomic Time (SAT)" before a new UTC was adopted in 1970 and implemented in 1972. This change also adopted leap seconds to simplify future adjustments.

A number of proposals have been made to replace UTC with a new system that would eliminate leap seconds. A decision whether to remove them altogether has been deferred until 2023.

So I guess you are saying that in 2023, you would vote to eliminate leap seconds. That's fine.

But in the meantime, it is very important to adhere to whatever the standard says. Adherence can have negative consequences if not handled correctly.

From an IT standpoint, it costs time and money. I once worked for an organization that billed by the hour. Whenever any change was made to billing software, it had to be tested for 23, 24, and 25 hour day use cases. How many IT shops do you think have tested the negative leap second use case, when they were told the popular view that negative leap seconds can never occur?

In #2, you said that NTP is enough. But have you seen a statement from whoever maintains NTP that it has been tested for the negative leap second case? I just searched and found this:

https://doc.ntp.org/reflib/leap/
# Although the definition also includes the possibility
# of dropping seconds (negative leap seconds), this has
# never been done and is unlikely to be necessary in the
# foreseeable future.
 
  • #25
pbuk said:
Actually GPS is one of the few things that is not based on UTC see https://gssc.esa.int/navipedia/index.php/Time_References_in_GNSS#GPS_Time_(GPST)
That's cool. I didn't know that. However the page linked says.

GLONASS Time (GLONASST) is generated by the GLONASS Central Synchroniser and the difference between the UTC(SU) and GLONASST should not exceed 1 millisecond plus three hours\
So, has it been tested for cases where the difference is greater? The whole point of this thread is software use cases that have never been tested.
 
  • #26
anorlunda said:
So, has it been tested for cases where the difference is greater? The whole point of this thread is software use cases that have never been tested.
Well ISTR that the cumulative leap second offset is stored in each satellite as a 256 bit value: not sure if that is signed (probably not given that nobody thought the day would reduce below 86,400s when leap seconds were introduced).

Plenty of scope for overflow errors there!
 
  • #27
anorlunda said:
So, has it been tested for cases where the difference is greater? The whole point of this thread is software use cases that have never been tested.
GLONASS is the Russian system (hence the 3 hours). Heaven only knows what they have tested it for and we can only hope that there are no missile launch systems that will auto-launch if they think the US has sped up the Earth's rotation.
 
  • #28
pbuk said:
would be a lot of fun.
OK, you got me. It might be more fun that I thought.
 
  • #29
pbuk said:
Indeed: I don't know anyone that understands the issues that thinks differently.
I do know quite a few people involved in time keeping; (including people who serve on the relevant committees) and while some of them do indeed want to change the system, some of them don't (for a variety of reasons). This has been an ongoing debate for a long time and I would be extremely surprised if anything changes in 2023; it would require a number of countries to change their current position. which is highly unlikely (it would be common knowledge by now).
Note that this would have to be a unanimous decision; meaning you need all of the governments of the countries that contribute to the UTC to agree. Needless to say, making any form of change takes a lot of time.
 
Last edited:
  • Informative
  • Like
Likes anorlunda and pbuk
  • #30
One small 1.59 millisecond for man, too many leap seconds for mankind.
 
  • Haha
Likes anorlunda
  • #31
One small 1.59 millisecond for man, too many leap seconds for mankind.
 
  • #32
anorlunda said:
Therefore, Meta concludes, we should simply "stop the future introduction of
leap seconds."
I agree as well.

I'm surprised that something like an "Arbitrary Machine Time" (Defined as never having leap seconds, and not being connected to the rotation of the Earth.) doesn't already exist, as it would be a useful tool to keep track of all the leap seconds that have occurred in the past. Right now if you want to know exactly how many seconds have occurred since some arbitrary date decades ago, you can't just use subtraction. You have to look up the history of all those leap seconds and manually adjust.

When a leap second happens, do they transmit to the Voyager probes and tell them to adjust their clocks? I hope not! It seems safer and easier to convert "Voyager time" to familiar units back on Earth as needed.
The leap second was introduced in 1972 and since then 27 leap seconds have been added to UTC. - Wikipedia
If some application needs to know the position of the Earth to this level of accuracy, being half-a-second off probably won't be good enough anyway, and would have to make local adjustments with or without leap seconds.
 
  • #33
Algr said:
I agree as well.

I'm surprised that something like an "Arbitrary Machine Time" (Defined as never having leap seconds, and not being connected to the rotation of the Earth.) doesn't already exist, as it would be a useful tool to keep track of all the leap seconds that have occurred in the past.
It does exist, it's called International Atomic Time (TAI). UTC is derived from TAI and it is UTC that must keep track of its cumulative difference from TAI (currently 37 seconds), not the other way round.
 
  • Like
  • Informative
Likes Algr and jedishrfu
  • #34
pbuk said:
International Atomic Time (TAI). UTC is derived from TAI and it is UTC that must keep track of its cumulative difference from TAI

The complexity mushrooms. We have two foundations for time.
  1. The scientifically defined second.
  2. The day and year tied to Earth's rotation and orbit. Commerce, school schedules, agriculture, prison sentences, ... will choose to use these units.
Derived units, minutes and hours, can be rooted on either. Your choice. The month and the calendar are already adapted to the year.

The problem occurs when we try to mash the two into a single unified standard. No matter how refined our science and technology, complexity and confusion will never become moot. Yet, I've never heard anyone suggest that we fully divorce the two systems.

Software, more than any other field, is saddled with the complexity of reconciling the two systems, because software serves both scientific and human purposes.
 
  • #35
For us the implementers, the algorithm is clear:
  • If NTP (or GPS or whatever) tells us that we should add a leap second, the last minute befor midnight should contain 61 seconds.
  • If we are told that we should subract a leap second (or add a negative leap second), the last minute befor midnight should contain 59 seconds.
Ours is not to decide why, ours is to implement according to the specifications.
 

Hot Threads

Recent Insights

Back
Top