Re: Timing API issues with wall-clock time

On Tue, Apr 12, 2011 at 1:47 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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?
>

 A few of us had a brief discussion about it at lunch today and everyone
seemed to like it. People were using the terms "monotonic clock" and
"document time."

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.


That should be pretty safe for Navigation Timing, since all of the times
should be relatively close to the epoch time. I'm a little more concerned
about Resource Timing and User Timing, particularly on long running apps
like e-mail. The values returned by the API and the values returned by Date
could diverge quite a bit. For the longer lasting APIs, I think we need to
make it more clear we're using a monotonic clock. And it'd be nice to use
the same solution for all 3 timing APIs.

James