Peter Hansen <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
