[timingobject] Timestamps and reference clocks

ingararntzen has just created a new issue for 
https://github.com/webtiming/timingobject:

== Timestamps and reference clocks ==

There are currently some issues in the spec with respect to definition
 of timestamps and what clocks they are sampled from.

The main requirement is that there is agreement on what clock is being
 used by timing provider and timing object. In addition this clock 
must be available directly to the application using the timing object 
so that timestamps may make sense also externally to the timing 
object. Also, it should be known how this clock relates to epoch - new
 Date().getTime(). Finally, the clock should ideally be 
sub-millisecond and monotonic.

The HR-time (performance) gives us all of this, and the browser 
support seems to be quite good already [1]  I think we should simply 
require the use of this clock.

This would mean that the timing provider does not have to provide a 
now() function. It is simply responsible for delivering state vectors 
that are timestamped with the HR clock. This is also true for online 
timing providers - they must translate from the clock used by the 
online timing service into the HR-time clock which is client-specific.

One little thing to note - HR-time - performance.now() gives timestamp
 values where the unit is milliseconds. The timing object defines it 
rates velocity and acceleration as unit change per second. This is 
nice I think - because the timing object is often used to represent 
rate-change phenomena in the human realm.

I'll start updating the spec accordingly.

[1] http://caniuse.com/#feat=nav-timing

See https://github.com/webtiming/timingobject/issues/16

Received on Monday, 24 August 2015 09:20:19 UTC