Re: Timing API issues with wall-clock time

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.


-Olli

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