Why Does Your Computer’s Clock Drift? The Hidden Science Behind Time Sync

Why Computer Clocks Drift

Both mechanical clocks and computer hardware rely on crystal oscillators that vibrate at a fixed frequency when powered. The stability of this frequency depends on manufacturing tolerances and environmental factors such as temperature, causing a gradual drift of the local clock.

Automatic Time Calibration

Modern computers automatically synchronize their clocks with external time sources over a network. The external source is a time server that obtains its reference from national time‑distribution centers, which in turn derive time from atomic standards.

From Astronomical to Atomic Definition of a Second

Historically a day was defined by Earth’s rotation and a second as 1/86 400 of a day. Because Earth’s rotation is irregular (tidal forces, earthquakes, etc.), this definition is not stable over long periods.

In 1967 the International Bureau of Weights and Measures defined the second as the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium‑133 atom. Atomic clocks based on this transition achieve accuracies better than 1 × 10⁻⁹, i.e., a deviation of about one second in 20 million years.

Coordinated Universal Time (UTC) and Leap Seconds

To keep the highly stable atomic time (TAI) aligned with the traditional astronomical time (UT1), a leap second is inserted (or rarely removed) whenever the difference approaches 0.9 seconds. The combined system is called Coordinated Universal Time (UTC).

Network Time Protocol (NTP)

NTP exchanges timestamps in network packets to estimate round‑trip delay and clock offset. Using four timestamps (t1‑t4) the calculations are:

Network delay = (t4 − t1) − (t3 − t2)

Clock offset = ((t2 − t1) + (t3 − t4)) ⁄ 2

Clients adjust their clocks based on the offset, achieving sub‑millisecond accuracy on LANs and 10‑500 ms on WANs.

Wall Clock vs. Monotonic Clock

Most programming language APIs return the “wall clock” (UTC). This clock can jump backward when a leap second or an NTP correction occurs, which may break software that assumes a continuously increasing time value.

A monotonic clock counts elapsed nanoseconds since system boot and never steps back. To avoid abrupt jumps, NTP provides two synchronization modes:

ntpdate : forces an immediate set of the system clock to the server time.

ntpd : slews the clock gradually, spreading the correction over time so the clock remains monotonic.

Time Distribution Infrastructure

National time centers (e.g., China’s National Time Service Center) broadcast UTC (plus local time‑zone offsets) via radio, network, and telephone links. Time servers receive this reference and redistribute it to end‑users and devices.

Practical Programming Considerations

When a program measures elapsed time, using a wall‑clock API can produce negative intervals if the clock is stepped back. Example in Go:

t1 := time.Now()
// system clock may be adjusted here
t2 := time.Now()
elapsed := t2.Sub(t1) // may be negative if t2 < t1

To avoid this, use a monotonic clock API (e.g., time.Now() in Go returns a monotonic component, or clock_gettime(CLOCK_MONOTONIC) in C).

Summary

Mechanical and crystal oscillators drift, so computers rely on NTP to synchronize with atomic‑based UTC. UTC incorporates leap seconds to keep atomic time aligned with Earth’s rotation. Developers should prefer monotonic clocks for interval measurements and configure NTP daemons (ntpd) to slew adjustments rather than step the clock, ensuring time‑dependent software remains robust.