[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Kristján Valur Jónsson kristjan at ccpgames.com
Fri Apr 6 19:04:44 CEST 2012


This is the most amusing of discussions.
Teh key sentence here is "the clock may not be adjusted".  Slewing or accelerating a clock is nerely adding to the already present error of the pace of the clock.
Sometimes a clock runs fast, sometimes it runs slow.  This is without any purposeful slewing or accelerating made by the OS.  Notice how the C++ standard specifies nothing about the error of this steady rate, which is however always nonzero.  This implies that the error in the time, or the variations of its rate, are not important to the meaning of the standard.

The thing wich matters here is that the clock progresses forwards, matching the progress of real times, to some (unsopecified) precision.  It must not suddenly jump backwards or forwards because someone changed the timezone.  That is all that is implied.

Since the error of the clock is unspecified, (that is, the error in its rate of progress) it cannot matter if this rate is temporarily adjusted by hand.



K


________________________________________
Frá: python-dev-bounces+kristjan=ccpgames.com at python.org [python-dev-bounces+kristjan=ccpgames.com at python.org] fyrir hönd Victor Stinner [victor.stinner at gmail.com]
Sent: 6. apríl 2012 14:32
To: Zooko Wilcox-O'Hearn
Cc: Python-Dev
Efni: Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)


The C++ Timeout Specification uses the following definition: "Objects
of class steady_clock represent clocks for which values of time_point
advance at a steady rate relative to real time. That is, the clock may
not be adjusted."

Proposed time.monotonic() doesn't respect this definition because
CLOCK_MONOTONIC *is* adjusted (slewed) on Linux.


More information about the Python-Dev mailing list