[Python-Dev] PEP 418 is too divisive and confusing and should be postponed
victor.stinner at gmail.com
Thu Apr 5 12:32:45 CEST 2012
>>> Since the only monotonic clock that can be adjusted by NTP is Linux'
>>> CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
>>> give a clock that isn't adjusted by NTP.
>> I thought we decided that NTP adjustment isn't an issue, because
>> it's always gradual.
> Well, in timings it is an issue, but perhaps not a big one. :-)
> In any case, which one we use will not change the API, so if it is
> decided it is an issue, we can always more to CLOCK_MONOTONIC_RAW in
> the future, once Linux < 2.6.26 (or whatever it was) is deemed
I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
underlying clock source is unstable (unstable frequency), a delta of
two reads of the CLOCK_MONOTONIC clock is a result in *seconds*,
whereas CLOCK_MONOTONIC_RAW may use an unit a little bit bigger or
smaller than a second. time.monotonic() unit is the second, as written
in its documentation.
Linux is the OS providing the most reliable monotonic clock, why
should you use a not reliable monotonic clock instead?
NTP doesn't step CLOCK_MONOTONIC, it only slew it.
More information about the Python-Dev