Posted on 07/26/2022 10:56:58 AM PDT by ShadowAce
Google, Microsoft, Meta and Amazon launched a public effort Monday to scrap the leap second, an occasional extra tick that keeps clocks in sync with the Earth's actual rotation. US and French timekeeping authorities concur.
Since 1972, the world's timekeeping authorities have added a leap second 27 times to the global clock known as the International Atomic Time (TAI). Instead of 23:59:59 changing to 0:0:0 at midnight, an extra 23:59:60 is tucked in. That causes a lot of indigestion for computers, which rely on a network of precise timekeeping servers to schedule events and to record the exact sequence of activities like adding data to a database.
The temporal tweak causes more problems -- like internet outages -- than benefits, they say. And dealing with leap seconds ultimately is futile, the group argues, since the Earth's rotational speed hasn't actually changed much historically.
"We are predicting that if we just stick to the TAI without leap second observation, we should be good for at least 2,000 years," research scientist Ahmad Byagowi of Facebook parent company Meta said via email. "Perhaps at that point we might need to consider a correction.*
The tech giants and two key agencies agree that it's time to ditch the leap second. Those are the US National Institute of Standards and Technology (NIST) and its French equivalent, the Bureau International de Poids et Mesures (BIPM).
This governmental support is critical, given that ultimately it is governments and scientists -- not technology companies -- that are in charge of the world's global clock system.
The leap second change triggered a massive Reddit outage in 2012, as well as related problems at Mozilla, LinkedIn, Yelp and airline booking service Amadeus. In 2017, a leap second glitch at Cloudflare knocked a fraction of the network infrastructure company's customers' servers offline. Cloudflare's software, comparing two clocks, calculated that time had gone backward but couldn't properly handle that result.
Computers are really good at counting. But humans introduce irregularities like leap seconds that can throw a wrench in the works. One of the most infamous was the Y2K bug, when human-authored databases recorded only the last two digits of the year and messed up math when 1999 became 2000. A related problem is coming in 2038 when a 32-bit number that some computers use to count the seconds from Jan. 1, 1970, is no longer large enough.
And earlier this year, some websites choked when web browsers hit version 100 because they were programmed to deal with only two-digit version numbers.
To ease the problems with computer clocks that don't like 61-second minutes, Google pioneered the idea of the "leap smear" that makes the leap second's changes in many tiny steps over the course of a day.
Adding a leap second causes problems with computers. And at some point, we'd have to subtract one too -- something that's never happened -- and that would likely uncover new problems.
"It could have a devastating effect on the software relying on timers or schedulers," Byagowi and Meta engineer Oleg Obleukhov said in a blog post Monday.
There’s a lot of acronyms and abbreviations (AAA) in this one minor article (OMA).
hold on a second...
That's better than a lot of articles.
> “It could have a devastating effect on the software relying on timers or schedulers”
This is bullshit. Individual computer clocks get set both forward and backward all the time.
Developers, deal with it. You like a challenge, right?
‘Leap Year’ has an entirely different meaning in Westeros. Winter is staying.
Computers are continuously being time corrected — and restarted/recreated
Time is what we never have enough of when we’re in a hurry
Anyone who has an outage because of leap seconds is an idiot. Leap seconds are something that happens, becauses of changes to the Earth’s rotation. Plan for it. This isn’t something that came up just yesterday. They are also widely advertised. So far, all leap seconds have been in the forward direction, but the protocol allows for backward leap seconds as well. I’ll bet one of them would really freak these people out.
NTP can be configured to automatically check and update the leapsecond file. This stuff isn’t rocket science.
Only the interval? So "events" are outside of time? Timeless?
Maybe MS-Windows computers are, but real computers can run for a long time without being restarted.
That said, worrying about leap seconds is a waste of time. Critical software should be designed to deal with the very occasional 61 or 58 second minutes. When you hit one, you can have a process look up and validate leap-seconds.list if it's important to you.
Every linux distro that I worked with including slack had NTP configured because the h/w was unreliable. Regarding the many rtos systems I worked with, there was never a dependency on a h/w-based wall clock. Not saying there’s no such thing, but most prolly rely on an external references.
Interesting. I took a look at my ntp configuration, and docs, and found there was an ‘update-leap’ command, but it didn’t work...
$ sudo update-leap
No leapfile directive in /etc/ntp.conf; leapfile location not known
$ grep leapfile /etc/ntp.conf
leapfile /etc/leap-seconds.list
Turns out, update-leap has a bug. The filename has to be quoted.
After editing the file...
$ sudo update-leap
Not time to replace /etc/leap-seconds.list
$grep leapfile /etc/ntp.conf
leapfile “/etc/leap-seconds.list”
I remember my IT department staying overnight to deal with the Y2K disaster. We didn’t have a single incident.
But we had spent the better part of a year fixing our systems to handle 4 digit years.
I can't think of many systems that would crater over a 61-second minute, then again, nothing I support these days considers time that critical. I have worked on systems where it would have mattered though. It was a really kick-ass fault tolerant unix box (Stratus) that processed and cut call detail records. Billing could easily have been impacted by something like that, but we had programmers who knew that, and actual test systems that we could test with.
This was back when Y2K was a thing, and we actually tested the Y2038 issue as well, when the unix 'time' counter rolls over. That had interesting results.
Speaking of which 2028 is coming.... glad I'll be retired by then.
The article mentions 23:59:60 implying the correction happens at the end of the day, but I imagine a correction would be less disturbing by sitting on 12:00:00 AM for the extra second given the disturbance can be washed over the following minutes. But the question, which time zone? Perhaps UTC -12:00
The article doesn’t correctly explain “32-bit” Unix issue. A 32-bit number can easily take us into the next millennium (0..4,294,967,295). The issue concerns the signed 32-bit number which we know is limited to the max value of 2147483647 (-2147483648..2147483647)
Good points regarding replication and minute granularity. Another reason why likely better to hold on the initial second of the hour at UTC -12:00.
Good question. I can't really recall. I think it's UTC, which for me would be -5 or -6 depending upon the time of the year. Most computers use UTC internally these days, even though most folk don't know that. It is one of the reason they ask for your timezone when installing the OS. The time that you see is calculated from the offset.NIST.gov has a lot of time-related information on their site. They might have more info about when changes are supposed to occur
I have computers that I support that I actually configure as UTC since they are in multiple time zones, and I want the log file time/date stamps to be in sync when troubleshooting.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.