Determining actual elapsed (wall-clock) time

[Roy Smith]

Peter Hansen <peter at engcorp.com> wrote:
> I would like to determine the "actual" elapsed time of an operation 
> which could take place during a time change, in a platform-independent 
> manner (at least across Linux/Windows machines).
> 
> Using time.time() doesn't appear to be suitable, since time might jump 
> forwards or backwards at the user's whim, if the system clock is reset, 
> or when a daylight savings time change occurs.

If you get the UTC time, daylight savings time doesn't enter the equation.  
If the system clock is reset, however, you're out of luck.  I can't think 
of any time-related API which doesn't rely on the system clock as a 
reference.  If the system clock is good, you get good time.  If the system 
clock sucks, or changes, you don't.

If you care about time, you want your system clock controlled by NTP.  
There's just no excuse not to.

Is there some reason you can't just use the system clock?  I suppose if you 
had to, you could hobble together your own NTP client which keeps network 
time independent of the system clock.  But that would be a lot of work and 
it's hard to imagine the effort would be justified.