Why is clock skew uncertainty critical to Spanner's TrueTime API?

TrueTime's core insight is refusing to pretend clocks are perfectly synchronized. Every physical clock, even GPS and atomic-clock-disciplined ones, drifts slightly, so instead of returning a single "current time" value that might be wrong by an unknown margin, TrueTime returns an interval [earliest, latest] and a mathematical guarantee that real time falls somewhere inside it.

That explicit uncertainty bound (epsilon), typically a few milliseconds, is exactly what commit wait is built around: Spanner deliberately delays acknowledging a commit until epsilon has definitely elapsed, guaranteeing the assigned timestamp is safely in the past everywhere before any other transaction could observe a smaller one. If Spanner instead trusted a single unsynchronized clock reading, two transactions on different machines could be assigned timestamps that don't reflect their real commit order, silently breaking external consistency without any error being raised.

The size of epsilon also has a direct performance cost: a larger uncertainty window means a longer commit wait, so Google invests heavily in GPS and atomic clock hardware specifically to keep epsilon small (single-digit milliseconds), which is why TrueTime's accuracy is treated as a first-class piece of infrastructure rather than an implementation detail.