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

Steven D'Aprano 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
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
```