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....@python.org [python-dev-bounces+kristjan=ccpgames....@python.org] fyrir hönd Victor Stinner [victor.stin...@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. _______________________________________________ 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
