[Python-Dev] Drop the new time.wallclock() function?

[Zooko Wilcox-O'Hearn]

On Mon, Mar 26, 2012 at 5:07 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:
>>
>> If someone has a use case which fits the "steady or else fall back to wall clock" pattern, I would like to learn about it.
>
> Python 3.2 doesn't provide a monotonic clock, so most program uses time.time() even if a monotonic clock would be better in some functions. For these programs, you can replace time.time() by time.steady() where you need to compute a time delta (e.g. compute a timeout) to avoid issues with the system clock update. The idea is to improve the program without refusing to start if no monotonic clock is available.

I agree that this is a reasonable use case. I think of it as basically
being a kind of backward-compatibility, for situations where an
unsteady clock is okay, and a steady clock isn't available. Twisted
faces a similar issue:

http://twistedmatrix.com/trac/ticket/2424

It might good for use cases like this to explicitly implement the
try-and-fallback, since they might have specific needs about how it is
done. For one thing, some such uses may need to emit a warning, or
even to require the caller to explicitly override, such a refusing to
start if a steady clock isn't available unless the user specifies
"--unsteady-clock-ok".

For motivating examples, consider software written using Twisted >
12.0 or Python > 3.2 which is using a clock to drive real world
sensing and control -- measuring the position of a machine and using
time deltas to calculate the machine's velocity, in order to
automatically control the motion of the machine. For some uses, it is
okay if the measurement could, in rare cases, be drastically wrong.
For other uses, that is not an acceptable risk.

One reason I'm sensitive to this issue is that I work in the field of
security, and making the behavior dependent on the system clock
extends the "reliance set", i.e. the set of things that an attacker
could use against you. For example, if your robot depends on the
system clock for its sensing and control, and if your system clock
obeys NTP, then the set of things that an attacker could use against
you includes your NTP servers. If your robot depends instead on a
steady clock, then NTP servers are not in the reliance set.

Now, if your control platform doesn't have a steady clock, you may
choose to go ahead, while making sure that the NTP servers are
authenticated, or you may choose to disable NTP on the control
platform, etc., but that choice might need to be made explicitly by
the operator, rather than automatically by the library.

Regards,

Zooko