[whatwg] Timeouts and monotonic vs clock time

[and-py]

Here's a curious little issue.

When you use `setTimeout` or `setInterval`, the HTML5 spec seems to say
that the callback should occur after a certain amount of actual time has
elapsed.

But what browsers might do is take the system clock, add the given
number of milliseconds and call back when that system clock time is
reached. The firing time will differ from the actual-elapsed-time, if
the system clock is changed in between the setting and the calling of
the callback.

What browsers actually do here varies:

* IE (8) and Opera (10) follow the delay-based behaviour.

* When moving the clock forward, Firefox (4) and Safari (5) act
clock-based: they immediately fire any interval or timeout whose
deadline has passed, and continue calling intervals at their period
thereafter.

* When moving the clock backwards, Firefox and Safari call the next
firing of each interval once on the delay basis, and then wait until the
system clock has caught up with the clock time that the interval would
have fired after that if the clock hadn't been changed.

* When moving the clock backwards, Firefox calls timeouts on a delay
basis, whereas Safari waits until the clock has caught up with the time
they would have fired.

* Chrome (5) is a strange case. Moving the clock forwards works on a
delay basis like IE/Opera. But Chrome refuses to acknowledge the clock
moving backwards. Timeouts and intervals fire at the expected times and
`new Date()` returns a falsified time that continues to march into the
future as if the clock had not been touched.  However, after some delay
(about 10 seconds?) all timeouts and intervals pause, until *longer*
than the clock time would take to catch up. I have no clue what's
happening here, but the wonky-Date continues to manifest on all pages
until Chrome is quit.

Can it be confirmed that the delay-based behaviour is what is intended
and should be implemented by browsers? This would seem to be the
most-likely-useful behaviour: animations, pollers, games and other
timeout-dependent applications shouldn't stop working just because the
clock has gone backwards (especially as this may have occurred in the
background without user interaction, due to a time synchronisation
daemon).

There still remains the problem of time confusion for well-behaved
applications that use the value of `new Date()` to pace or synchronise
themselves. I don't know if Chrome's odd Date behaviour is a (failed)
attempt to work around this problem or just a bug, but it would seem
very useful for applications to be able to measure real elapsed time
without having to worry about shifting clocks.

For example a `getMonotonicTime()` method on `window` returning the
`Number` of milliseconds elapsed since some arbitrary time (perhaps
since the beginning of loading the current document, or just a
per-document random epoch).

Anyone else think this is worth working on, or experienced similar odd
browser behaviours?

-- 
And Clover
mailto:and at doxdesk.com http://www.doxdesk.com
skype:uknrbobince gtalk:chat?jid=bobince at gmail.com