[Python-Dev] PEP 418: Add monotonic clock

[Lennart Regebro]

Reading this discussion, my conclusion is that not only us are
confused, but everyone is. I think therefore, that the way forward is
to only expose underlying API functions, and pretty much have no
intelligence at all.

At a higher level, we have two different "desires" here. You may want
a monotonic clock, or you may not care. You may want high resolution,
or you might not care. Which one is more important is something only
you know. Therefore, we must have, at the minimum, a function that
returns the highest resolution monotonic clock possible, as well as a
function that returns the highest resolution system/wall clock
possible. We also need ways to figure out what the resolution is of
these clocks.

In addition to that, you may have the requirement that the monotonic
clock also should not be able to jump forward, but if I understand
things correctly, most current OS's will not guarantee this. You may
also have the requirement that the clock not only does not jump
forward, but that it doesn't go faster or slower. Some clock
implementations will speed up or slow down the monotonic clock,
without jumps, to sync up with the wall clock. It seems only Unix
provides a monotonic clock (CLOCK_MONOTONIC_RAW) that does not get
adjusted at all.

Now between all these requirements, only you know which one is more
important? Do you primarily want a raw monotonic clock, and
secondarily high resolution, or is the resolution more important than
it being monotonic? (Because if you need a high resolution, you are
usually measuring small timeframes, and the clock is more unlikely to
be adjusted, for example).

Since there is no obvious "A is better than B that is better than C"
we first of all have to expose the underlying API's somehow, to allow
people to make their own decisions. Secondly, since apparently not
only python-dev, but many others as well, are a bit confused on this
complex issue, I'm not sure we can provide any high-level functions
that makes a best choice.

As such the proposed time.monotonic() to get the monotonic clock on
the various systems makes a lot of sense to me. It should get the
highest resolution available on the system. Get GetTickCount64() of
available on Windows, else GetTickCount(). The function could have a
raw=False parameter to select between clock_gettime(CLOCK_MONOTONIC)
and clock_gettime(CLOCK_MONOTONIC_RAW) on Unix, and it would get
mach_absolute_time() on OS X.

If no monotonic clock is available, it should raise an error.The same
if you pass in raw=True and there is no monotonic clock that has no
adjustments available.

In the same vein, time.time() should provide the highest resolution
system clock/wall clock available.

We also need functions or attributes to get the resolution of these clocks.


But a time.steady() that tries to get a "best case" doesn't make sense
at this time, as apparently nobody knows what a best case is, or what
it should be called, except that it should apparently not be called
steady(). Since monotonic() raises an error if there is no monotonic
clock available, implementing your own fallback is trivial in any
case.

//Lennart