RE: Disparity between time bases in HighResolutionTime and ResourceTiming

Yes, the fact that is monotonically increasing and isn't does make comparing the two unreliable. We can evangelize this fact, but there is no way to enforce that developers will not compare the two.

This discussion is independent on whether we use the proposed or current design for the High Resolution Time timebase origin.

From: James Robinson []
Sent: Thursday, August 30, 2012 8:17 PM
To: James Simonsen
Cc: Jatinder Mann;
Subject: Re: Disparity between time bases in HighResolutionTime and ResourceTiming

On Thu, Aug 30, 2012 at 8:08 PM, James Simonsen <<>> wrote:
On Thu, Aug 30, 2012 at 5:59 PM, Jatinder Mann <<>> wrote:

 Also I should add, though we may not want to encourage it, developers can always compare High Resolution Time with by just adding performance.navigationStart to the call. (In the current definition, they would add their document's performance.navigationStart and with the proposed definition, they would add the parent.performance.navigationStart). This time will only be accurate to the millisecond, but will truly be comparable. and are not anything close to comparable.  They will advance at different rates on different people's computes. is not necessarily nondecreasing, let alone monotonic.  If you have a value it tells you something about what that user's system clock thinks the time is at the time you called, but it doesn't tell you anything else.  If you have a value it tells you how much wall clock time has elapsed since a previous time you called or since a marker uses the clock.  Any code that mixes with is not just inaccurate, it's flat out wrong.

This concern is not theoretical - we've observed widespread clock skew including clocks going backwards by doing experiments in the wild that compare time intervals against server side times.

Is this spec'd somewhere? I was always under the impression should change if the user's clock changes. That's how Chrome works anyway.

James is right - changes if the system clock changes.

 - James

Received on Saturday, 1 September 2012 00:06:46 UTC