[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)
Stephen J. Turnbull
stephen at xemacs.org
Sat Apr 7 11:42:29 CEST 2012
On Sat, Apr 7, 2012 at 8:47 AM, Victor Stinner <victor.stinner at gmail.com> wrote:
> "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."
> I don't understand this definition. All clocks have a clock drift. [[...]]
> you can use a NTP daemon to adjust automatically using a free farm
> of atomic clocks distributed around the world.
That's inside the black box; C++ doesn't care about *how* the clock is
made to be steady by the system. The system could incorporate an
atomic clock, or it could use NTP to keep the clock closely
corresponding to physical time. The C++ program doesn't ask, and the
system shouldn't tell.
> So you can get a cheap steady clock if you accept that (OMG!) it can
> be adjusted.
> Or did I misunderstand "the clock may not be adjusted"?
I think you are not keeping your context consistent with the viewpoint
of the C++ committee. To the C++ committee, a steady clock may be
expected to "just keep ticking" as far as the C++ program is
concerned. What this means is that the clock value is incremented in
sequence: it never goes backward, and it never "jumps over" a possible
time value. How closely that "ticking" approximates physical time is
Somebody Else's Problem; C++ simply assumes that it does.
In other words, a clock adjustment in the C++ standard means that the
clock's reported time values occur out of sequence. However, if the
intervals between clock ticks are adjusted by NTP (or by a little old
Swiss watchmaker moving the pendulum bob) in order to improve its
steadiness (ie, accurate correspondence to physical time), C++ doesn't
know about that, and doesn't care.
Amusingly enough, various people's statements about common usage of
"monotonic" notwithstanding, C++'s definition of "monotonic" was
"mathematically monotonic." Cf. N3092, 20.10.1.
More information about the Python-Dev