> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com