W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2011

Re: Timing API issues with wall-clock time

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 12 Apr 2011 13:47:36 -0700
Message-ID: <4DA4BA68.6090802@mit.edu>
To: James Simonsen <simonjam@chromium.org>
CC: public-web-perf@w3.org
On 4/12/11 12:57 PM, James Simonsen wrote:
> One of the original goals was to be able to compare easily with Date
> objects. Instead of that, perhaps we should expose a monotonic clock to
> the page?

Longer-term, I think that this is the right direction to go.  Gecko 
already uses a monotonic clock internally for its animations and then 
has to do some hackery to report "corresponding" times to the web page 
that are compatible with JS Date...  Exposing a monotonic clock to pages 
would solve that problem.

On the other hand, an issue with monotonic clocks is that you can't 
really use them to record "the time right now" except in some sort of 
opaque timestamp format.  They're very good for measuring time 
intervals, of course.  Are people ok with exposing opaque timestamps 
(that can't necessarily be converted to wall-clock time, etc) to JS?

For the particular case of navigation timing one possibility is that the 
page load start is recorded as wall-clock epoch time and the other times 
reported by the interface are defined in terms of a monotonic clock 
measuring time elapsed from the page load start.  That would be 
API-compatible with the existing spec, I think, but ensure that the 
differences between the reported numbers actually correspond to elapsed 
durations.

-Boris
Received on Tuesday, 12 April 2011 20:48:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:30 UTC