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

[noreply@sourceforge.net]

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: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: time.time() is not non-decreasing

Initial Comment:
<p>After spending many hours tracking down weird race
conditions in <a href="http://mojonation.net/">Mojo
Nation</a>, I've finally realized that the problem is
that we assumed that <cite>time.time()</cite> would
return non-decreasing answers.  In fact, successive
calls to <cite>time.time()</cite> can return a
<em>smaller</em> number than previous calls, as
demonstrated by this test (Python 2.0 on debian
woody):</p>
<pre>
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 ".",
</pre>
<p>In order to get the race conditions out of Mojo
Nation, I'm writing a
<cite>non_decreasing_time()</cite>, which does what we
thought <cite>time()</cite> would do.  In fact, I might
just make it <cite>increasing_time()</cite>.  In any
case, the <cite>time.time()</cite> 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.</p>
<p>Regards,</p>
<p><b><i>Zooko</i></b></p>

----------------------------------------------------------------------

>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