> If we provide a way to check if the monotonic clock is monotonic (or
> not), I agree to drop the flag from time.monotonic(fallback=True) and
> always fallback. I was never a fan of the "truly monotonic clock".
>
> time.clock_info('monotonic')['is_monotonic'] is a good candidate to
> store this information.
I updated the PEP to add time.get_clock_info() and to drop the
fallback parameter of time.monotonic() (which now always falls back).
Because "monotonic" word cannot define time.monotonic() anymore, I
suggest to rename the time.monotonic() function to time.steady(). So
we would have:
- time.steady() may or may not be monotonic, but its is as steady as possible.
- time.get_clock_info('steady')['is_monotonic'] which looks less
surprising than time.get_clock_info('monotonic')['is_monotonic']
It doesn't follow the C++ steady_clock definition, but it looks like
the Boost library doesn't follow the C++ definition... (it uses
CLOCK_MONOTONIC on Linux)
By the way, it now prefer to use CLOCK_MONOTONIC instead of
CLOCK_MONOTONIC_RAW on Linux. It is what I need in practice. If the
hardware clock is a little bit too fast or too slow, NTP adjusts its
rate so a delta of two timestamps is really a number of seconds. It's
not yet written explicitly in the PEP, but the unit of
time.monotonic/time.steady and time.highres is a second.
Victor
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4