There Is No Global Clock

The natural fix is to synchronise clocks, and NTP does exactly that: a node measures the round trip to a time server and splits the difference. The split assumes the path is symmetric — that the request took as long as the response. Under load, or across an asymmetric route, it does not, and the error is half the asymmetry. That is why practical synchronisation gives you *bounds* of a few milliseconds on a well-run network and occasional excursions of far more, rather than an exact offset.

Then there is drift: a quartz oscillator runs fast or slow by tens of parts per million, so an unsynchronised clock accumulates error continuously. And there is correction: when the daemon notices the error, it either steps the clock — which can move it backwards — or slews it, which makes the clock temporarily run at the wrong rate. Both of those break code that assumed time is monotonic, which is why Never Measure a Duration With the Wall Clock is a separate lesson and why measuring a duration with a wall clock is a bug.

The tightest available answer is a clock that reports an *interval* rather than an instant — "now is somewhere in [t₁, t₂]" — using disciplined hardware. That does not eliminate uncertainty; it makes it explicit, so a system can wait out the interval when it needs certainty and skip the wait when it does not. Paying real latency to buy an ordering guarantee is the honest shape of the trade.

When you write if (a.ts > b.ts) for events from different hosts, you are asserting that the clock difference between those hosts is smaller than the time between the events. For events seconds apart on a healthy network, that assertion usually holds. For events milliseconds apart — which is precisely when the ordering question arises — it frequently does not.

This is the flaw at the heart of last-write-wins conflict resolution, and it is worth stating in its most uncomfortable form: last-write-wins does not keep the last write. It keeps the write from the host with the furthest-ahead clock. A node whose clock is 200ms fast wins every conflict for 200ms of real time, including against writes that genuinely came later and even against writes that causally *depend* on data it has not seen. Last Write Wins Is Data Loss You Chose by Default does this properly; the point here is that the flaw is in the clock, not in the merge rule.

Worse, the failure is silent. Nothing errors. The data converges, the metrics are clean, and one user’s change disappeared. This class of bug is found by customers, not by monitoring, which is why the reasoning has to happen at design time.

If timestamps cannot order events, something must. The answer is the only thing nodes genuinely share: messages. If A sent a message and B received it, then everything A did before sending precedes everything B does after receiving. Chain those edges together and you get a partial order that is true by construction rather than by assumption — no clock required.

It is a *partial* order, and that is not a defect. Two events with no chain of messages between them are genuinely concurrent: no observer could have distinguished their order, and the system is free to choose. The mistake is inventing a total order where only a partial one exists, and then relying on it. Lamport clocks and version vectors are the mechanisms; Happens-Before: The Only Ordering You Actually Have and Vector Clocks: Buying Concurrency Detection at O(N) do them properly, and Concurrency’s happens-before is the same idea inside one machine, where the edges come from memory barriers instead of messages.

When you genuinely need a total order — a ledger, a replicated log, a sequence of commands every replica must apply identically — you do not get it from clocks. You get it from an agreement protocol that assigns positions, which is what Total Order Broadcast Is Consensus Wearing a Different Hat and the whole consensus module are for, and it costs a round trip to a majority for every entry.

None of this means timestamps are useless. They are the right tool whenever the question is human-facing rather than correctness-critical: displaying when something happened, expiring a cache, choosing a retention window, bucketing metrics. The rule of thumb is that a clock is fine for anything where being a few hundred milliseconds wrong is a cosmetic problem.

They are also fine, and necessary, for bounding things: a lease that expires, a token that becomes invalid, a deadline. Note the shape of those uses — they rely on elapsed time on one machine, not on comparing instants across machines, and they should be measured with a monotonic clock. The dangerous case is narrow and specific: using a wall-clock reading from one host to order or compare against a reading from another.

One caveat that catches people out: a lease is safe only if the granter and the holder agree about elapsed duration, which they do not exactly. Real lease protocols therefore have the holder treat its lease as expiring *earlier* than the granter does, so the gap absorbs the drift. That asymmetry is the practical form of "do not trust clocks across hosts" — see Leases: Authority With an Expiry Date.