By J. H. Saltzer, April 21, 1996.

The paper doesn't say this, but Coda uses the system clock to generate
the storeid nonce.  I run a sales route for a potato chip company
based in Riggins, Idaho, and I take a laptop along to record
inventories in each store that I visit.  As I drive the few miles south to
New Meadows, Idaho, I pass a sign alerting me to change my watch because
Riggins is on Pacific Time but New Meadows was on Mountain Time.  I don't
have a watch, so I adjust the clock in my laptop.

When I get back, I reconcile the laptop with my desktop computer using
Coda.  Then I run out to check an inventory in a local store, and on
return do another reconciliation.  But one of the updates I made while
on the road didn't appear in my desktop system.  Why not?
(Because you set the clock back an hour, and you managed to generate a
duplicate nonce, so your file looks unmodified.  the last-modified
timestamps on the changed files appear to be *earlier* than the time of
the previous reintegration.

This bug shows the importance of uniform time-keeping
in distributed systems. If both the desktop and the laptop keep time in
GMT rather than local time, and maintain a separate offset value for
use in displaying local time, then a Coda-style algorithm can be
programmed to work correctly--assuming that the clocks run at the same
rate.  But if either of the machines keeps time in local time this bug
will probably appear.  It can even appear in a system that tries to
maintain GMT time plus an offset if the user doesn't understand the
reason why there are two clock variables and adjusts the wrong one when
trying to compensate for time changes.)