Keeping accurate time is much harder than a clock suggests

This is less a set of instructions about computer timekeeping than an argument, and it is worth saying so at the start.

Every clock drifts

A computer keeps time with a quartz oscillator whose frequency varies with temperature, age and manufacturing tolerance. The resulting drift is small per second and accumulates to seconds or minutes over days. Temperature-compensated oscillators reduce it at a cost, and atomic references remove it at a much larger cost.

Consumer devices therefore rely on regular correction from an external source rather than on accuracy of their own.

Synchronisation measures the network, not just the time

A time protocol exchanges timestamps in both directions and uses them to estimate the round-trip delay. Assuming the delay is symmetric, half of it is the one-way offset, which is subtracted to recover the true time.

In the datasheet, asymmetric paths break that assumption and are the main source of error in ordinary synchronisation. This is why accuracy is typically in the milliseconds over the internet and far better on a local network.

Adjusting time abruptly breaks things

Setting a clock backwards makes time appear to repeat, which corrupts logs, breaks scheduled tasks and confuses anything measuring intervals. Well-behaved systems therefore slew the clock, speeding it up or slowing it slightly until it converges.

In practice, software that needs to measure elapsed time should use a monotonic clock that never jumps, and a great deal of software does not. Bugs from this class appear rarely and are extremely difficult to reproduce.

Timezones are political data

Offsets, daylight saving rules and their start and end dates are set by legislation and change with some regularity around the world. That information is distributed as a database that must be updated on devices, which is why an out-of-date system shows the wrong local time after a rule change. Historical rules matter too, because converting a past timestamp requires the rules that applied then.

Storing timestamps in a universal reference and converting only for display avoids most of the resulting pain.

Leap seconds and the mess they cause

The rotation of the Earth is irregular, so occasional leap seconds have been inserted to keep civil time aligned with astronomical time. A repeated or extended second breaks software that assumes minutes always contain sixty seconds, and outages have resulted. Some large operators smear the adjustment across many hours instead, which avoids the discontinuity and means their clocks briefly disagree with everyone else.

The practice is under active international review, which is a reminder that even the definition of a day is maintained by committee.

Figures here are typical rather than guaranteed — check the spec sheet for your part.

Where precision genuinely matters

Distributed databases use time to order events, and clock error directly limits how confidently they can do so. Financial trading records, industrial control and scientific measurement have regulatory or physical requirements far tighter than ordinary synchronisation provides.

Those settings use dedicated hardware, satellite references or precision protocols that timestamp packets in the network interface itself. For everything else, ordinary synchronisation is invisible when it works and the cause of baffling bugs when it does not.

The takeaway

The clock drifts, the network lies about delay, and the timezone rules change by law. All three need handling.

Once you know what it is trading away, the design stops looking arbitrary.