Three hilltops, three bell towers, each cut off from the others by a valley. In every tower lives a keeper whose job is to stamp passing contracts with the hour they were sealed. The trouble: no clock is true. The keeper’s pocket watch runs fast one day and slow the next, and the valley wind tells its own lies.

Yet the old keeper never says “it is noon.” He only ever says “it is somewhere between the first and the second stroke of noon” — always a range, never a point. To keep that range narrow he calibrates every noon against the sundial in the yard (the sun cannot be bribed), and leans on the great pendulum that swings in the tower day and night to hold him steady between calibrations. The sundial gives direction, the pendulum gives constancy; squeezed between the two, his window of doubt shrinks to no more than a few held breaths.

The real craft is in the stamping. When a contract is ready for the wax, the keeper takes the latest hour in his range and writes that down. But he does not ring at once. He counts on his fingers and waits — until even his most pessimistic guess has run past the hour he wrote, until he is certain “this very moment has truly passed the number I stamped.” Only then does he strike the bronze bell that means “this contract is sealed.”

That pause looks like wasted time, and it is the whole point. Because of it, the very next contract sealed on any hilltop — no matter how fast or slow that keeper’s watch — must carry an hour later than this one. The three hills never need a shared clock, and no one can ever swap two contracts’ order: whoever sealed first carries the smaller number, always.

— By now you have probably recognized it: this is Google Spanner’s TrueTime and commit-wait.

TrueTime does not return an instant like an ordinary clock; it returns an interval [earliest, latest] and guarantees the true time lies within it — it makes the clock’s uncertainty ε explicit. That interval is kept narrow by GPS receivers and atomic clocks in every datacenter. To commit a transaction, the coordinator picks a commit timestamp s, then deliberately waits until TT.after(s) is true (until even the interval’s lower bound has passed s) before releasing locks and committing. That deliberate wait is commit-wait, and it buys external consistency (linearizability): any transaction that begins afterward is guaranteed a strictly greater timestamp, so datacenters spread across the globe can agree on one consistent ordering of all transactions without ever sharing a clock. The width of the interval (about 2ε, usually a few milliseconds) sets how long that wait must be — which is why Google spends so much effort driving the clock error down.

Metaphor mapping:

• The three hilltop bell towers → datacenters spread across the globe
• The keeper’s unreliable pocket watch → the local machine clock that drifts
• The sundial in the yard + the ever-swinging pendulum → GPS receivers + atomic clocks
• Never saying “noon,” only “between the first and second stroke” → TT.now() returning an interval [earliest, latest], exposing uncertainty ε
• The narrowed window of doubt → the uncertainty 2ε
• Stamping with the latest hour in the range → choosing the commit timestamp s
• The extra beat counted out before ringing → commit-wait, waiting until TT.after(s) is true
• A later-sealed contract always carrying a larger number → external consistency / linearizability