RE: Timing API issues with wall-clock time

IE currently calculates the timestamps as Boris describes.

We'd support a change in the spec to recommend this approach, though picking simple wording to describe it may be tricky.

- Nic

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of James Simonsen
Sent: Tuesday, April 12, 2011 2:28 PM
To: Boris Zbarsky
Cc: public-web-perf@w3.org
Subject: Re: Timing API issues with wall-clock time

On Tue, Apr 12, 2011 at 1:47 PM, Boris Zbarsky <bzbarsky@mit.edu<mailto: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