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
Interest
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
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 la
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
> -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
> If you get the UTC time, daylight savings time doesn't enter
> the equation.
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 ap
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.
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 persiste
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 e
[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
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 sav
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. The
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'
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 ab
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 tim
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
16 matches
Mail list logo
