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

Re: Timing API issues with wall-clock time

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Tue, 12 Apr 2011 14:37:58 -0700
Message-ID: <4DA4C636.4090802@helsinki.fi>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: James Simonsen <simonjam@chromium.org>, public-web-perf@w3.org
On 04/12/2011 01:47 PM, Boris Zbarsky wrote:
> 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

If web developers are already complaining about this bug in the
spec, it is better to fix it now.
I support what Boris suggested above.

Received on Tuesday, 12 April 2011 21:39:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:07 UTC