What is clock drift?

A device keeps time by counting the ticks of an oscillator, and no oscillator runs at exactly its nominal rate. Lamport’s 1978 paper on distributed clocks puts it plainly: since two different clocks never run at exactly the same rate, they tend to drift further and further apart.

The Network Time Protocol (NTP) specification, RFC 5905, describes a clock’s error with two quantities. The time offset is how far the clock is from the reference now. The frequency offset is how fast that error grows, which the RFC expresses in parts per million (ppm), where 1 ppm is one microsecond of error per second. A clock with a constant frequency offset gains or loses the same amount every day, so the longer it runs without correction, the further off it gets.

How large drift is depends on the hardware and its conditions. NTPv4 does make one working assumption about it. When a synchronised clock loses its sources and is left to drift, the protocol assumes a worst-case frequency tolerance of 15 ppm, and the specification notes that this amounts to about 1.3 seconds per day. That is an upper bound NTP uses for its error estimates, not a measurement of any particular device, but it shows the scale: at that rate, a clock left alone for a week would be several seconds out.

Devices correct drift by comparing themselves with a better clock:

• NTP over a network. NIST notes that Windows, macOS and Linux can synchronise the system clock automatically by querying an NTP server, as a background process that starts at boot. NIST’s own stratum-1 servers are directly linked to UTC(NIST), the official NIST time.
• The phone network. Android’s automatic time detection uses NTP servers and NITZ, time signals from the mobile network, by default. Both need a connection to an external network, which the Android documentation notes is not always available.
• Satellites. Each GPS satellite carries several atomic clocks, and GPS.gov says receivers can use the signals to determine the time to within 100 billionths of a second. Android supports a GNSS time source from Android 12, though not by default.

NTP corrects small and large errors differently. If the measured offset is below the step threshold, 125 milliseconds in RFC 5905, the clock is adjusted gradually. Above it, the clock is stepped straight to the correct time, and above a panic threshold of 1000 seconds the specification says the program should exit with a diagnostic message rather than set the clock.

Correction creates its own problem. Android’s documentation warns that the standard wall clock can be set by the user or the phone network, so it “may jump backwards or forwards unpredictably”, and recommends a different, monotonic clock for measuring intervals. Leap seconds add another irregularity: NIST describes servers that repeat a second, and systems that smear the extra second over a longer period instead, which it says can last several hours, which keeps the clock from stopping but leaves it slightly off UTC during the adjustment.

For anyone recording events, this means a timestamp from a device’s wall clock is an estimate. It can be wrong by however much the device drifted, and two consecutive timestamps can even appear in the wrong order after a correction. Keeping event order offline covers alternatives that do not depend on the wall clock.

Drift causes failures wherever software compares a timestamp with its own idea of now:

• Certificates. RFC 8915, which secures NTP with TLS, points out the circularity: a client checking a certificate’s validity period needs a correct clock, but it is connecting to get the correct time. It lists mitigations, such as recording the last known good time and rejecting certificates that expired before it.
• Freshness and replay checks. Messages that must be recent are rejected if the receiver’s clock is wrong. Offline Protocol’s security page lists this as a residual risk: freshness checks on control messages depend on the verifier’s clock, so a wrong clock can reject legitimate control frames.
• Ordering and conflict rules. Any rule that keeps the change with the highest timestamp, such as last writer wins, lets a device with a fast clock win conflicts it should lose.
• Stored data. Readings stamped with a drifted clock land at the wrong point on a chart, which is why a time-series database used for device data benefits from storing the server’s receive time as well.

Time sources also need protecting. NIST notes that its standard time requests generally do not support authentication, and RFC 8915 defines Network Time Security so that a client can check that time replies are genuine.