Unreliable Clocks

Clocks on different machines drift and are never perfectly synchronized, so timestamps cannot be trusted to order events across nodes. Time-of-day clocks can even jump backward when corrected; only a monotonic clock reliably measures elapsed time on a single machine, and neither orders events across machines.

Why it Matters

Distributed code that uses wall-clock timestamps to decide ordering or "who wrote last" is silently wrong, because clock skew can exceed the interval between the events being compared. Causality, not timestamps, is what actually orders distributed events.

Signals

• "Last write wins" by comparing timestamps generated on different nodes.
• Using wall-clock time to measure a timeout or to generate ordering.
• Assuming two machines' clocks agree closely enough to compare.

Benefits

Distinguishing wall-clock from monotonic time, and ordering by logical or causal mechanisms, avoids data loss and incorrect ordering.

Risks

Dropping or overwriting data because one node's clock ran ahead; measuring elapsed time with a time-of-day clock and getting negative or jumping durations; a lease judged unexpired because of skew, letting two holders coexist.

Tensions

Timestamps are convenient and human-meaningful but unreliable for ordering; logical clocks order correctly but lose the link to real wall-clock time.

Examples

Two writes to the same key resolved by timestamp, silently discarding the genuinely later one; a distributed lock whose expiry is misjudged because clocks disagree.