Why One Critical Second Can Wreak Havoc on the Internet

CNet ^ | 25 July 2025 | Stephen Shankland

[webheart]

There’s a lot of acronyms and abbreviations (AAA) in this one minor article (OMA).

[heavy metal]

hold on a second...

[Bratch]

[ShadowAce]

At least they do explain them when used for the first time.

That's better than a lot of articles.

[old-ager]

> “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?

[Tallguy]

‘Leap Year’ has an entirely different meaning in Westeros. Winter is staying.

[Gene Eric]

Computers are continuously being time corrected — and restarted/recreated

[Hot Tabasco]

Time is what we never have enough of when we’re in a hurry

[zeugma]

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.

[Psalm 73]

"Time is the interval between events"

Only the interval? So "events" are outside of time? Timeless?

[zeugma]

Computers are continuously being time corrected — and restarted/recreated

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.

[Gene Eric]

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.

[zeugma]

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”

[gitmo]

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.

[zeugma]

I think the biggest problems come from transaction reconciliation or log shipping and/or replicaton on very fast databases. However, your transaction logs and such should be aware that both a 59 and 61 second minute is possible.

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.

[tanstaafl.72555]

Time is the interval between events

Interval of what?

[Gene Eric]

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.

[zeugma]

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

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.