> Gah, just when you think you can trust time.nist.gov

You still can...

If you're that considered about 5 microseconds: Build your own Stratum 1 time server https://github.com/geerlingguy/time-pi

or just use ntppool https://www.ntppool.org/en/

I'm more concerned about what you think they did to earn your trust in the first place

their handling it responsibly seems like more evidence for trusting them, not less?

Most places that need accurate time get it from GPS. That is 10-100 ns.

Also, you can use multiple NIST servers. They have ones in Fort Collins, CO and Gaithersburg, MD. Most places shouldn't use NIST directly but Stratum 1 name servers.

Finally, NTP isn't accurate enough, 10-100 ms, for microsecond error to matter.

Use the other servers as well: https://tf.nist.gov/tf-cgi/servers.cgi

For instance, time-a-wwv.nist.gov.

One should configure a number of different NTP sources instead of just a single host.

It's a good question, and I wondered the same. I don't know, but I'd postulate:

As it stands at the minute, the clocks are a mere 5 microseconds out and will slowly get better over time. This isn't even in the error measurement range and so they know it's not going to have a major effect on anything.

When the event started and they lost power and access to the site, they also lost their management access to the clocks as well. At this point they don't know how wrong the clocks are, or how more wrong they're going to get.

If someone restores power to the campus, the clocks are going to be online (all the switches and routers connecting them to the internet suddenly boot up), before they've had a chance to get admin control back. If something happened when they were offline and the clocks drifted significantly, then when they came online half the world might decide to believe them and suddenly step change to follow them. This could cause absolute havoc.

Potentially safer to scram something than have it come back online in an unknown state, especially if (lots of) other things are are going to react to it.

In the last NIST post, someone linked to The Time Rift of 2100: How We lost the Future --- and Gained the Past. It's a short story that highlights some of the dangers of fractured time in a world that uses high precision timing to let things talk to each other: https://tech.slashdot.org/comments.pl?sid=7132077&cid=493082...

The 5us inaccuracy is basically irrelevant to NTP users, from the second update to the Internet Time Service mailing list[1]:

To put a deviation of a few microseconds in context, the NIST time scale usually performs about five thousand times better than this at the nanosecond scale by composing a special statistical average of many clocks. Such precision is important for scientific applications, telecommunications, critical infrastructure, and integrity monitoring of positioning systems. But this precision is not achievable with time transfer over the public Internet; uncertainties on the order of 1 millisecond (one thousandth of one second) are more typical due to asymmetry and fluctuations in packet delay.

[1] https://groups.google.com/a/list.nist.gov/g/internet-time-se...

You probably want to ask about accuracy. Any random microcontroller from the 90s needs microsecond precision.

The high frequency trading guys

edit: also the linked slides in TFA

We use nanosecond precision driven by GPS clocks. That timestamp in conjunction with star tracker systems gives us reliable positioning information for orbital entities.

https://en.wikipedia.org/wiki/Star_tracker

I mean, we routinely benchmark things that take microseconds or less. I've seen a 300 picosecond microbenchmark (single cycle at 3GHz). No requirement that absolute time is correct, though.

We need nanosecond precision for trading - basically timestamping exchange/own/other events and to measure latency.

Telecom.

Precision Time Protocol gets you sub-microsecond.

https://en.wikipedia.org/wiki/Precision_Time_Protocol

We don't use NTP, but for robotics, stereo camera synchronization we often want the two frames to be within ~10us of eachother. For sensor fusion we then also need a lidar on PTP time to be translated to the same clock domain as cameras, for which we also need <~10us.

We actually disable NTP entirely (run it once per day or at boot) to avoid clocks jumping while recording data.

(Assuming "precision" really meant "accuracy") The network equipment I work on requires sub microsecond time sync on the network for 5G providers and financial trading customers. Ideally they'd just get it from GPS direct, but that can be difficult to do for a rack full of servers. Most of the other PTP use cases I work with seem to be fine with multiples of microseconds, e.g. Audio/Video over the network or factory floor things like PLCs tend to be find with a few us over the network.

Perhaps a bit more boring than one might assume :).

Lots of things do. Shoot, even plain old TDM needs timing precision on the order of picoseconds to nanoseconds.

Look up PTP White Rabbit.