Should time-origin and Date.now be related?

[toddreifsteck]

See https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7167808/

As of today, ECMAScript and HR-Time do not seem to explicitly require an exact relation between the time origin and Date.now(). This can cause some confusion as can be seen in the linked Microsoft Edge issue.

What do folks think about whether this is something worth addressing?
(It seems like a minor expansion of the active globalOffset proposal from my point of view.)

[toddreifsteck]

ECMAScript link--https://tc39.github.io/ecma262/#sec-date.now

[toddreifsteck]

Also.. this requires a reference to http://www.w3.org/TR/navigation-timing-2/#widl-PerformanceTiming-navigationStart

[igrigorik]

According to the spec the time origin for high resolution timestamp should be equivalent to |performance.timing.navigationStart| (at least when navigating between two documents).

Note exactly.. timing.navigationStart is NT1, which doesn't define time origin and instead provides millisecond granularity "in milliseconds since midnight of January 1, 1970 (UTC)". We defined time origin and HR-Time in NT2, which you access via: performance.getEntriesByType('navigation')[0]. </nitpick>

|(Date.now() - performance.timing.navigationStart) - performance.now()| ... In my tests I see a varying value that goes up to 15ms in EdgeHTML. This is unexpected and I believe is incorrect. This simple test page shows this (let it run for multiple reloads to see the effect).

@toddreifsteck not sure how it's implemented in Edge nowadays, but historically.. this is not surprising: http://ejohn.org/blog/accuracy-of-javascript-time/. Also, wouldn't the above expression be subject to clock skew and all the other reason why we introduced HR-Time? I'd say the above is expected. Surprising.. but expected.

---

Above aside, what exactly do you have in mind with "relation between ECMAScript and HR-Time"? Also, it's also not entirely clear to me (yet?) that we need to tie globalOffset to UTC..

[toddreifsteck]

Times used to be commonly tied to low resolution intervals and were effectively clamped to 16 ms in ~Windows XP. When I tested in Microsoft Edge on my Surface Book (Skylake), I found that Date.now() will increment every 1 ms but I did not drill into the details of the implementation so it is possible that could vary with hardware.

I posted this issue as I wanted to track this issue and have not yet settled on my thoughts with regard to a proposal. I'll think through it then post again with a summary of what could improve this.

[majido]

I filed the original EdgeHTML bug. So here are some thoughts:

Thanks for the nitpick @igrigorik. You are right about timing.navigationStart being legacy interface but according to the definitions in the specs, all three: timing.navigationStart, performance.getEntriesByType('navigation')[0] and time origin should define the same moment in time. The wording is different between specs but it amounts to the same thing and I think we all agree on this point.

I'd say the above is expected. Surprising.. but expected.
Perhaps expected in Windows XP, Vista whose time implementation was buggy but not Windows 10 with latest Edge.

So ignoring the historical implementation bugs I believe the expectation is as following:

1. timing.navigationStart is the same as hr time origin.
2. Date.now should have a resolution of 1 millisecond. ecma262
3. Performance.now should have a sub-millisecond resolution (at best 5 microseconds). hr-time2

This supports my original expectation around bounds on (Date.now() - performance.timing.navigationStart) - performance.now()

wouldn't the above expression be subject to clock skew and all the other reason why we introduced HR-Time?

Yes it would be subject to these skews. Unfortunately there is no way around that but I appreciate if we don't add additional unexpected skews. I am not advocating for adoption of such a transformation in general but they may be necessary in contexts of a polyfill (here is mine).

[majido]

We defined time origin and HR-Time in NT2, which you access via: performance.getEntriesByType('navigation')[0].

Are you sure? All time values in NT2 are hr-time. So it does not seem possible to use that as a way to correlate time origin with a wall time value.

I could always take a snapshot of Date.now() and performance.now() at "one moment in time" and do the transformation that way but it I was hoping that using timing.navigationStart will be more accurate which is the case on all modern browsers except Edge.

minor expansion of the active globalOffset proposal

This looks like an interesting proposal. Any link?

[igrigorik]

Stepping back.. The core issue here is that you're comparing a monotonic clock that's guaranteed to tick at a constant rate vs a clock that provides no such guarantee and can be adjusted at runtime and/or skewed by the system (via NTP, etc). As such, the results are not surprising... for example, nothing stops the system from rewinding system time and/or jumping it ahead on next iteration of your test; such is the joy of system time.

As a corollary, performance.timing.navigationStart only provides a snapshot against system time at a particular point and the system time may have been adjusted many times over since then.. so subtracting said value from Date.now() can yield arbitrary values, which is exactly what you're observing.

I think this is a wontfix. If you want strict guarantees on your clock you need to use a monotonic clock.. and all math and comparisons should be against said clock.

[toddreifsteck]

I agree this is Won't Fix or... By Design. At the same time, it is probably useful for UAs to ensure that their navigation start is somewhat in sync with Date when the timestamp is first created. Any significant variance between the two would be unusual though not strictly required by specs.

[igrigorik]

@toddreifsteck so, anything spec-actionable here? I'm inclined to close this with no action.

[toddreifsteck]

Agreed. If anything the note suggested for #21 may clarify this a bit.