Re: Determining actual elapsed (wall-clock) time

2005-07-07 Thread zooko
The traditional use of gettimeofday() to (insecurely and unreliably) approximate elapsed local time is one of my pet peeves. Fortunately a real monotonic clock has finally been added to the linux kernel and glibc: http://www.imperialviolet.org/page24.html#e474 If you have a recent enough kernel

Re: Determining actual elapsed (wall-clock) time

2005-07-07 Thread Peter Hansen
zooko wrote: The traditional use of gettimeofday() to (insecurely and unreliably) approximate elapsed local time is one of my pet peeves. Fortunately a real monotonic clock has finally been added to the linux kernel and glibc: http://www.imperialviolet.org/page24.html#e474 Interestingly,

RE: Determining actual elapsed (wall-clock) time

2005-07-04 Thread Coates, Steve (ACHE)
-Original Message- From: Roy Smith [mailto:[EMAIL PROTECTED] Sent: 02 July 2005 21:22 To: python-list@python.org Subject: Re: Determining actual elapsed (wall-clock) time SNIP If you get the UTC time, daylight savings time doesn't enter the equation. If the system clock

Re: Determining actual elapsed (wall-clock) time

2005-07-04 Thread Peter Hansen
Coates, Steve (ACHE) wrote: There is already an NTP client in the ASPN cookbook :- http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/117211 Thanks Steve. As it turns out, Windows XP already has support (via NTP I presume, though of course since this is Microsoft they try to keep the

Re: Determining actual elapsed (wall-clock) time

2005-07-04 Thread Roy Smith
Peter Hansen [EMAIL PROTECTED] wrote: As it turns out, Windows XP already has support (via NTP I presume, though of course since this is Microsoft they try to keep the user base ignorant by making no mention of that even in the help page) for keeping the clock accurate, right on the last

Re: Determining actual elapsed (wall-clock) time

2005-07-03 Thread Bengt Richter
On Sat, 2 Jul 2005 19:44:19 -0400, Tim Peters [EMAIL PROTECTED] wrote: [Peter Hansen] Hmmm... not only that, but at least under XP the return value of time.time() _is_ UTC. At least, it's entirely unaffected by the daylight savings time change, or (apparently) by changes in time zone. On all

Re: Determining actual elapsed (wall-clock) time

2005-07-03 Thread Aahz
In article [EMAIL PROTECTED], 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

Determining actual elapsed (wall-clock) time

2005-07-02 Thread Peter Hansen
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

Re: Determining actual elapsed (wall-clock) time

2005-07-02 Thread Peter Hansen
Roy Smith wrote: Peter Hansen [EMAIL PROTECTED] wrote: If you get the UTC time, daylight savings time doesn't enter the equation. Of course... I didn't think of that approach. I don't actually care about absolute time, so this should work fine for at least the DST case. If you care about

Re: Determining actual elapsed (wall-clock) time

2005-07-02 Thread Roy Smith
Peter Hansen [EMAIL PROTECTED] wrote: I guess as long as the NTP client is set up to ensure the time adjustments are smaller than some value X, it would be acceptable. NTP is generally capable of keeping the various system clocks on a LAN within a few ms of each other, and within a few 10's

Re: Determining actual elapsed (wall-clock) time

2005-07-02 Thread Peter Hansen
Roy Smith wrote: Peter Hansen [EMAIL PROTECTED] wrote: I'll have to look into how to set up Windows XP to prevent users from changing the time on their own, assuming that's possible. On a single-user system like Windows, you pretty much have to assume the user can do anything. They can

Re: Determining actual elapsed (wall-clock) time

2005-07-02 Thread Peter Hansen
Roy Smith wrote: Peter Hansen [EMAIL PROTECTED] wrote: 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

Re: Determining actual elapsed (wall-clock) time

2005-07-02 Thread Tim Peters
[Peter Hansen] Hmmm... not only that, but at least under XP the return value of time.time() _is_ UTC. At least, it's entirely unaffected by the daylight savings time change, or (apparently) by changes in time zone. On all platforms, time.time() returns the number of seconds since the epoch.

Re: Determining actual elapsed (wall-clock) time

2005-07-02 Thread John Machin
Roy Smith wrote: Peter Hansen [EMAIL PROTECTED] wrote: I guess as long as the NTP client is set up to ensure the time adjustments are smaller than some value X, it would be acceptable. NTP is generally capable of keeping the various system clocks on a LAN within a few ms of each other,

Re: Determining actual elapsed (wall-clock) time

2005-07-02 Thread flamesrock
I've needed to do something similar in the past and used free ntp servers. Of course you need an internet connection: http://ntp.isc.org/bin/view/Servers/NTPPoolServers http://www.nightsong.com/phr/python/setclock.py You could also have a startup script spawn a thread that stores the time