Why you can't trust a clock across machines

A computer's internal clock is a physical oscillator, and no two oscillators run at exactly the same rate — one machine's clock might run a few milliseconds fast per day, another slightly slow, purely from hardware variance and temperature. This is called clock drift, and left alone, it accumulates: two machines that started perfectly in sync will measurably disagree after enough time passes.

The Network Time Protocol (NTP) periodically corrects a machine's clock against reference time servers, but this correction itself takes non-zero time to travel over a network with variable latency — the correction is an estimate, not a perfect sync. In practice, even well-configured NTP leaves machines disagreeing by anywhere from single-digit to tens of milliseconds, and poorly configured or network-degraded setups can be far worse. This gap is small enough to ignore for almost everything humans do directly, and large enough to break naive assumptions in software that compares timestamps from different machines.

If Server A logs an event at 14:00:00.010 and Server B logs a different event at 14:00:00.005, it's tempting to conclude A's event happened after B's — but if the two clocks disagree by more than 5 milliseconds (entirely plausible), that conclusion could be backwards. This matters concretely: imagine two updates to the same record arriving at different replicas with different local timestamps — "last write wins by timestamp" is a genuinely common conflict-resolution strategy, and it can silently pick the wrong write if the clocks disagree by more than the gap between the two writes.

Software-corrected clocks don't just drift — an NTP correction can actually move a clock backwards in time to fix an overshoot, meaning System.currentTimeMillis()-style calls are not guaranteed to be monotonically increasing even on a single machine, let alone comparable across two. Code that assumes "later call, later timestamp, always" can be wrong even without involving a second machine at all.

Since physical clocks can't be trusted to establish a reliable ordering between events on different machines, distributed systems that genuinely need to know "did A happen before B" reach for a different tool entirely: logical clocks, covered in the next lesson, which capture the causal relationship between events directly — using message-passing itself as the signal — rather than trying to squeeze more precision out of physical clocks that are fundamentally unreliable for this purpose.

Not every clock-related fear is about cross-machine comparison — a single machine's own clock, if read carelessly, can also jump due to an NTP correction on that same machine. For measuring elapsed time on one machine (like a timeout or a duration), most languages expose a separate monotonic clock guaranteed to never go backwards, precisely to avoid this narrower version of the same underlying problem.