time

If you’re trying to build reliable web applications, you might have wondered what happens to existing timeouts and intervals after the system clock jumps. Not that clock jumps happen very often, but it’s nice to think of setTimeout(func, 0) (or similar) as a reliable abstraction. Unfortunately, it isn’t. See Clock jump test page for the results of my testing, or to do your own tests.

In some browsers on some OSes, if the clock jumps backwards, an existing timer might not fire for a long time. If the clock jumps forwards, an existing timer might fire too early, possibly causing misbehavior if you were relying on a correct time duration.

A summary of the test page: IE and Opera on any OS use the monotonic clock to schedule timeouts. Firefox on Windows uses the monotonic clock, but a setInterval timer is broken after a backwards clock jump. Every other OS/browser combination schedules by the system time, or behaves strangely when the time jumps.

Here’s the bug for Chromium, but a lot more bugs need to be filed.

Python’s time.time() jumps around if the system time changes. The monotonic clock doesn’t, and climbs steadily upwards. Unfortunately, Python doesn’t give you easy access to the monotonic clock. A 50-line Python module may help you out, at least if you have a POSIX-like OS that has librt (I tested only Linux).

Get it at: https://github.com/ludios/Monoclock

Let me know if it works, or doesn’t. Please contribute, especially if you’ve implemented Windows or OS X support.