Fixing clock skew

[Conrad Minshall]

At 12:49 AM -0400 5/28/03, Ben Creech wrote:
>Would you have the user stop the system clock until Father Time catches up?

Perhaps yes, and via adjtime.  Anyway, settimeofday on some unixes 
doesn't support decreasing the system time, because it is a Bad 
Thing...

>Why, in particular, is it a bad thing?

Data loss.  An example I saw was code which depended on modifying two 
files and the timestamps reflecting that ordering.  If it saw the 
second file had an earlier timestamp it took that as an indication 
that the previous modification-pair had been interrupted, probably by 
a system crash.  It went downhill from there.

Event loss.  Consider a change detection algorithms which looks for 
an increased modification time... retrograde timestamps can let 
changes go undetected, potentially forever.

Event replication.  Events triggered by an absolute system time may 
be triggered a second time, with arbitrary consequences.

>Are you hinting at something security-related?

Like cloaking when a breach happened, to hinder post-mortem analysis? 
Or some NTP based attack?  Here I'm only guessing.

>Obviously some things will such as make-based
>systems will need to be cleaned, etc, but I will assume that if the
>user clicks "yes" to the dialog box that they're aware of the
>effects.

Bad assumption.  Non-decreasing time is a lot like arithmetic 
overflow... programmers often don't consider the possibility.  That's 
reality.  But how could a user be expected to be aware of the effects 
of the non-decreasing presumption hidden in code which is executed on 
their behalf?
-- 
Conrad Minshall h:408-446-2323 rad at acm.org / w:408-974-2749 conrad at apple.com