RE: Disparity between time bases in HighResolutionTime and ResourceTiming

Yes, the fact that performance.now() is monotonically increasing and Date.now() 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 [mailto:jamesr@google.com]
Sent: Thursday, August 30, 2012 8:17 PM
To: James Simonsen
Cc: Jatinder Mann; public-web-perf@w3.org
Subject: Re: Disparity between time bases in HighResolutionTime and ResourceTiming


On Thu, Aug 30, 2012 at 8:08 PM, James Simonsen <simonjam@chromium.org<mailto:simonjam@chromium.org>> wrote:
On Thu, Aug 30, 2012 at 5:59 PM, Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote:

 Also I should add, though we may not want to encourage it, developers can always compare High Resolution Time with Date.now() by just adding performance.navigationStart to the performance.now() 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.


Date.now() and performance.now() are not anything close to comparable.  They will advance at different rates on different people's computes.  Date.now() is not necessarily nondecreasing, let alone monotonic.  If you have a Date.now() value it tells you something about what that user's system clock thinks the time is at the time you called Date.now(), but it doesn't tell you anything else.  If you have a performance.now() value it tells you how much wall clock time has elapsed since a previous time you called performance.now() or since a marker uses the performance.now() clock.  Any code that mixes Date.now() with performance.now() 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 Date.now() time intervals against server side times.


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


James is right - Date.now() changes if the system clock changes.

 - James