[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: 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:
<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: 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