<div class="gmail_quote">On 6 April 2012 02:50, Cameron Simpson <span dir="ltr"><<a href="mailto:cs@zip.com.au">cs@zip.com.au</a>></span> wrote:</div><div class="gmail_quote">(Quoted from the Linux manpage)<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":1mt">All implementations support the system-wide real-time clock, which<br>
is identified by CLOCK_REALTIME. Its time represents seconds and<br>
nanoseconds since the Epoch. When its time is changed, timers for<br>
a relative interval are unaffected, but timers for an absolute point<br>
in time are affected.<br></div></blockquote></div><br><div>This made me think. They make a distinction between "timers for a relative interval" and "timers for an absolute point in time".</div><div>
<br></div><div>But that's not right - *all* of the clock calls we are talking about here return a *single* number. Interpreting that as an absolute time needs an epoch. Or to put it another way, clock values are always meaningless without context - whereas clock *differences* are what actually carry meaning (in terms of a duration).</div>
<div><br></div><div>On that basis, I'd say that</div><div><br></div><div>- A clock that doesn't get adjusted or slewed is a tick counter (which technically doesn't have any relationship to time, although the tick frequency can be used to convert to seconds, but see the next entry)</div>
<div>- A clock that gets slewed but not adjusted is a seconds counter (or at least, the nearest approximation the system can provide - presumably better than a tick counter)</div><div>- A clock that gets adjusted is not an interval timer at all, but an absolute timer (which therefore shouldn't really be used for benchmarking or timeouts)</div>
<div><br></div><div>It seems to me that what *I* would most often need are the second two of these (to at least as high a precision as my app needs, which may vary but "to the highest precision possible" would do :-)) I'd be happy for a seconds counter to fallback to a tick counter converted to seconds using its frequency - slewing is simply an accuracy improvement process, as far as I can see.</div>
<div><br></div><div>It seems to me that the current time.time() and time.wallclock() are the right names for my "absolute timer" and "seconds timer" above. Whether their implementations match my definitions I'm not sure, but that's what I'd hope. One thing I would expect is that time.wallclock() would never go backwards (so differences are always positive). The various other debates about monotonic, steady, etc, seem to me to be only relevant for specialist uses that I don't care about.</div>
<div><br></div><div>As regards suspension, if I'm timing intervals and the system suspends, I'd be happy to say all bets are off. Similarly with timeouts. If I cared, I'd simply make sure the system didn't suspend :-)</div>
<div><br></div><div>As far as comparability between different threads or processes are concerned, I would expect absolute time (time.time) to be the same across threads or processes (but wouldn't generally write apps that were affected if it weren't - at least by small amounts), but I wouldn't expect time.wallclock values obtained in different threads or processes to be comparable (mostly because I can't think of a case where I'd compare them). Where VMs or multiple machines are involved, I wouldn't even expect absolute time to match (but that's the job of NTP, and if time.time follows NTP, there's no reason why there would be an issue even there).</div>
<div><br></div><div>Summary: I'm happy with time.time and time.wallclock. The rest of this debate doesn't matter for my usecases (and I suspect many other people's in practice).</div><div><br></div><div>[Update, after I downloaded and installed 3.3a2] Bah, looks like time.wallclock is gone. (Actually, looks like it was documented but not implemented in 3.3a1!). Actually, the docs and the implementation don't match - clock_gettime is documented as available, but it's not (at least on Windows). I still prefer time.wallclock() as described above and in the 3.3a1 documentation. I thought I knew what was going on, but now I'm confused. My comments above still stand, though.</div>
<div><br></div><div>Paul.</div>