Use case and full example: https://www.w3.org/TR/hr-time-3/#examples
> A developer may wish to construct a timeline of their entire application, including
> events from dedicated or shared workers, which have different time origin's. To
> display such events on the same timeline, the application can translate the
> DOMHighResTimeStamp's with the help of the performance.timeOrigin attribute.
Definition: https://www.w3.org/TR/hr-time-3/#dom-performance-timeorigin
> The timeOrigin attribute must return a DOMHighResTimeStamp representing the high
> resolution time of the time origin timestamp of the global object.
---
Also, contribute tests for it @ https://github.com/w3c/web-platform-tests/tree/master/hr-time
Could you clarify the definition? Let's just consider the most substantial part: it is the "sum of the high resolution Unix time at which the global monotonic clock is zero and the time value of the global monotonic clock at which the time origin is zero".
How do we calculate the Unix time being referred to? I thought the point of the monotonic clock is to prevent using unreliable system clocks. And what does 'time value [...] at which time origin is zero' mean? From what I understand, given an object, the time origin is a fixed timestamp.
I have a CL with what I would expect the implementation to be (just a way to expose a high resolution timestamp of the time origin) but I'd like to first understand the definition in the spec.
https://chromium-review.googlesource.com/c/574829
There are a few moving bits here:
- each renderer has a time origin and own monotonic clock
- browser has a *global* monotonic clock shared by renderers, and a unix timestamp of when the global clock is zero
To obtain "timeOrigin" value for a render, you take the unix timestamp of when global monotonic clock is zero, and add the time value of the global monotonic clock for when time origin of the renderer is zero (i.e. when it was launched).
Hope that helps clarify things a bit?
> I thought the point of the monotonic clock is to prevent using unreliable system clocks.
Right, the resulting value is tied to a unix timestamp, but there is no guarantee that it's accurate.. Hence the "The time origin timestamp and the value returned by Date.now() executed at "zero time" can differ because the former is recorded with respect to a global monotonic clock that is not subject to system and user clock adjustments, clock skew, and so on" disclaimer in the spec.
Comment 1 by igrigo...@google.com
, Jul 5 2017Labels: Hotlist-PerformanceAPIs