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

Zooko Wilcox-O'Hearn zooko at zooko.com
Tue Mar 27 04:41:56 CEST 2012

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

More information about the Python-Dev mailing list