[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Paul Moore]

On 6 April 2012 02:50, Cameron Simpson <cs at zip.com.au> wrote:
(Quoted from the Linux manpage)

> All  implementations  support the system-wide real-time clock, which
>   is identified by CLOCK_REALTIME.  Its time represents seconds and
>   nanoseconds  since the Epoch.  When its time is changed, timers for
>   a relative interval are unaffected, but timers for an absolute point
>   in time  are affected.
>

This made me think. They make a distinction between "timers for a relative
interval" and "timers for an absolute point in time".

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).

On that basis, I'd say that

- 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)
- 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)
- 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)

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.

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.

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 :-)

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).

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).

[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.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120406/4203cb3d/attachment.html>