Re: [timingobject] Timestamps and reference clocks

Hmmm, this probably amounts to the same result in the end and thus it 
may be just a matter of taste, but I find it much more intuitive to 
ask the timing provider for an evaluation of the current time than to 
ask it for an evaluation of when a past event occurred (or perhaps 
more accurately for an evaluation of when a past event should be seen 
as having occurred to be able to compute the proper elapsed number of 
milliseconds).

I would rather keep `ts_init` constant in your example: it is the 
timing provider's evaluation of when the initial vector was set. When 
that evaluation was made, it was as accurate as possible, even though 
clocks may have drifted since then, so I don't see why it should 
change over time.

And I would thus ask the timing provider for an evaluation of 
`ts_now`. That's what the `now()` method does. This way, it exposes 
the software clock that the timing provider needs to maintain and keep
 in sync with the server clock. The user agent would then synchronize 
its internal software clock with this clock using any "usual" clock 
synchronization mechanism.

If the timing provider fails to implement a monotonic clock, the user 
agent could also use that synchronization opportunity to fix that 
(instead of throwing an `OperationError` as currently defined in the 
spec). Said differently, I would let the user agent handle the mapping
 between the clock exposed by the timing provider and the 
`performance.now()` timeline.

Actually, the time origin used by the timing provider does not even 
really matter (so values it reports do not necessarily have to be on 
the timeline of the `performance.now()` clock) since we're really just
 interested in computing differences between two timestamps.

Do you see any notable advantages or drawbacks with either approach?

-- 
GitHub Notif of comment by tidoust
See 
https://github.com/webtiming/timingobject/issues/16#issuecomment-134202853

Received on Monday, 24 August 2015 13:36:15 UTC