Determining actual elapsed (wall-clock) time
roy at panix.com
Sat Jul 2 22:22:15 CEST 2005
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.
More information about the Python-list