Author lemburg
Recipients brian.curtin, jnoller, kevinwatters, lemburg, nascheme, pitrou, rcohen, schmir
Date 2010-01-27.10:33:39
SpamBayes Score 1.11022e-16
Marked as misclassified No
Message-id <>
In-reply-to <20100126151155.5cda9e74@neeble>
Ross Cohen wrote:
> Ross Cohen <> added the comment:
> On Fri, 22 Jan 2010 09:32:36 +0000
> Marc-Andre Lemburg <> wrote:
>>  * Please add the fallback solutions from the time module in case gettimeofday() is not available. You cannot assume that "all modern POSIX systems" implement that API - it was introduced in POSIX 2001 and Python 2.x still supports OSes that were released prior to that year.
> POSIX as a standard tends to follow, not lead. The gettimeofday() call
> dates back over 20 years in BSD. time.time() falls back on ftime() and
> then time(). ftime() was added to the POSIX spec at the same time as
> gettimeofday() and is now deprecated. time() probably doesn't have
> enough resolution.
> I'd have to be pointed to a specific platform which doesn't support
> gettimeofday() but which is supported by python. Otherwise, I'd be
> coding blind.

The point here is that we have traditionally been careful not
to break Python for platforms that don't support a certain API,
hence the different fallback solutions for getting the current

gettimeofday() is indeed available on most OSes, but not all. VxWorks
is an example where it is not available and Python happily uses

There are also cases where gettimeofday() is buggy
(e.g. on Solaris: or
or returns errors every now and then (I have observed that in mxDateTime
occasionally - it may be related to NTP doing its works).

For those situations is necessary to be able to enable a
fallback solution using other APIs.

I've also done some extra research yesterday and found that e.g.
Ruby is using gettimeofday() for thread scheduling as well. They
have observed issues with gettimeofday() causing problems due
to wallclock time not being a monotonic (e.g. due to NTP running
on the machine and the clock sometimes going backwards due to
corrections or DST changes).

OTOH, using process timers is also not regarded as being ideal,
since on SMP systems, each CPU will have its own timer and they
are not necessarily in sync.

Other implementations tend to use the new clock_gettime() APIs
where available and then use the CLOCK_MONOTONIC timer, e.g.

Here's some example code which tries to cover even more platforms
than Python 2.x:

Another aspect to consider is update frequency of these APIs.
gettimeofday()'s resolution depends on various factors and
appears to vary between 1us and 100ms (on systems running using
a 100Hz clock).

clock_gettime() has similar resolution, but tends to be updated
more often:

And finally, using wallclock time for these things is expensive
as I've already mentioned:
(as HTML:

It appears to be better to use clock_gettime(CLOCK_MONOTONIC)
where available and only use gettimeofday() as fallback solution
together with times(), ftime() and time().
Date User Action Args
2010-01-27 10:33:50lemburgsetrecipients: + lemburg, nascheme, pitrou, schmir, kevinwatters, jnoller, brian.curtin, rcohen
2010-01-27 10:33:45lemburglinkissue7753 messages
2010-01-27 10:33:39lemburgcreate