Re: Disparity between time bases in HighResolutionTime and ResourceTiming

On Thu, Aug 30, 2012 at 8:08 PM, James Simonsen <simonjam@chromium.org>wrote:

> On Thu, Aug 30, 2012 at 5:59 PM, Jatinder Mann <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