[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

Fri Apr 6 04:23:07 CEST 2012

Greg Ewing wrote:
> Cameron Simpson wrote:
>>> A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
>> polls of the clock. On its own it says nothing about steadiness or
>> correlation with real world time.
>> No, no, no.
>> This is the strict mathematical meaning of the word "monotonic",
> but the way it's used in relation to OS clocks, it seems to
> mean rather more than that.
>> A clock whose only guarantee is that it never goes backwards
> is next to useless. For things like benchmarks and timeouts,
> the important thing about a clock that it *keeps going forward*

That would be a *strictly* monotonic clock, as opposed to merely monotonic.
And yes, a merely monotonic clock could just return a constant value, forever:
9, 9, 9, 9, 9, ...
and yes, such a thing would be useless.
Various people have suggested caching the last value of time() and re-using it 
if the new value is in the past. This will give a monotonic clock, but since 
it can give constant timestamps for an indefinite period, it's usefulness is 
limited.
I earlier put forward an alternate implementation which gives no more than one 
such constant tick in a row. If you know the hardware resolution of the clock, 
you can even avoid that single constant tick by always advancing the timestamp 
by that minimum resolution:
_prev = _prev_raw = 0
_res = 1e-9 # nanosecond resolution
def monotonic():
 global _prev, _prev_raw
 raw = time()
 delta = max(_res, raw - _prev_raw)
 _prev_raw = raw
 _prev += delta
 return _prev
Even if time() jumps backwards, or stays constant, monotonic() here will be 
strictly monotonic.
-- 
Steven