[Python-bugs-list] [ python-Bugs-447945 ] time.time() is not non-decreasing (original) (raw)

noreply@sourceforge.net noreply@sourceforge.net
Fri, 05 Oct 2001 16:02:26 -0700

Bugs item #447945, was opened at 2001-08-04 08:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447945&group_id=5470

Category: Documentation Group: Not a Bug Status: Closed Resolution: Fixed Priority: 5 Submitted By: Zooko Ozoko (zooko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: time.time() is not non-decreasing

Initial Comment:

After spending many hours tracking down weird race conditions in Mojo Nation, I've finally realized that the problem is that we assumed that time.time() would return non-decreasing answers. In fact, successive calls to time.time() can return a smaller number than previous calls, as demonstrated by this test (Python 2.0 on debian woody):

import time


x = 0
while 1:
    ox = x
    x = time.time()
    if x < ox:
        print "this is WRONG: ox: %s, x: %s\n" % (ox,
x,)
    else:
        print ".",

In order to get the race conditions out of Mojo Nation, I'm writing a non_decreasing_time(), which does what we thought time() would do. In fact, I might just make it increasing_time(). In any case, the time.time() in the standard library should either be fixed (my preference) to be non-decreasing, or the documentation should be updated to warn about the surprise.

Regards,

Zooko

Comment By: paul rubin (phr) Date: 2001-10-05 16:02

Message: Logged In: YES user_id=72053

You're using poor system software if it's setting the clock back to adjust for clock skew. The correct way to handle that is to slow down the clock updates slightly, so the correct time "catches up" with the clock time. That's the right way to do it because of the precise problem you encountered.

Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-05 08:44

Message: Logged In: YES user_id=3066

Added a note about time() being non-decreasing except when the system clock is set back; see Doc/lib/libtime.tex revision 1.43.

Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-04 13:01

Message: Logged In: YES user_id=6380

Zooko writes:

""" It turns out that it is because my system clock is getting reset, to adjust for clock skew.

I'm testing my new `increasing_time()' function which I can rely on to always return higher values. I'll post about it to python-list.

Sorry for the bug report which was really just a problem with a frequently misunderstood semantics. Perhaps the time.time() docs should warn you about the possibility of getting different results. """

Assigning to Fred for doco update.

Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-04 11:03

Message: Logged In: YES user_id=6380

I don't understand why this can happen. time.time() is a simple wrapper around either gettimeofday(), ftime(), or time(). So you should be able to reproduce this in C as well, and it should be a kernel bug, unless somehow the conversion to float is busted. Can you investigate?

Of course, if the super-user resets the system clock, time.time() may also return non-monononous values -- I assume that that's not what you're seeing -- but that's a reason why Python can't guarantee a monotonously increasing time.

You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447945&group_id=5470