Distributed systems use two very different notions of a clock. A physical clock reports real wall-clock time, the kind of time a person reads off a watch. A logical clock is just a counter that captures the order in which events happen, with no connection to real time at all. Each kind solves a different problem, and the trade-off between them is central to how distributed systems reason about time.
Physical clocks have the advantage of meaning: a physical timestamp can be compared against any other machine’s timestamp and against the outside world. Their weakness is that they drift and must be continually synchronized. The Network Time Protocol, specified in RFC 5905, exists to keep physical clocks across the Internet close to a reference, but even with NTP no two clocks are ever exactly equal, so a smaller physical timestamp does not reliably mean an earlier event.
Logical clocks sidestep that uncertainty. Leslie Lamport’s 1978 paper “Time, Clocks, and the Ordering of Events in a Distributed System,” on his publications page, introduces counters that advance with each event and message so that if one event causally precedes another, its logical timestamp is smaller. As Lamport puts it, the timestamps provide a total ordering consistent with the causal order. Logical clocks tell you the order of events without telling you when they happened in real time, and they never drift.
The two ideas are not mutually exclusive. Vector clocks extend logical clocks to capture the full causal partial order, and hybrid approaches such as Google’s TrueTime pair tightly bounded physical time with logical ordering to get the meaning of real timestamps and the safety of causal order at once. Choosing between physical and logical time, or combining them, is one of the recurring design decisions in distributed systems.