On Sat, Apr 7, 2012 at 8:47 AM, Victor Stinner <victor.stin...@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." > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady > > 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. (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf) Regards, _______________________________________________ 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
