[Python-Dev] PEP 418 is too divisive and confusing and should be postponed
steve at pearwood.info
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
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
global _prev, _prev_raw
raw = time()
delta = max(_res, raw - _prev_raw)
_prev_raw = raw
_prev += delta
Even if time() jumps backwards, or stays constant, monotonic() here will be
More information about the Python-Dev