RE: Potential Issue with DONHiResTimeStamp in WebRTC Stats API

Harald said: 

"The use of DOMHiResTimeStamp is actually troubling, for multiple reasons, none of which is actually a technical concern:

1) The name is wrong. It's DOMHighResTimeStamp.

2) The definition (which is a typedef for Double) states that "The DOMHighResTimeStamp type is used to store a time value measured relative to the navigationStart attribute of the PerformanceTiming interface [NavigationTiming], the start of navigation of the document, or a time value that represents a duration between two DOMHighResTimeStamps."

It also says that "The time values returned when calling the now method MUST be monotonically increasing and not subject to system clock adjustments or system clock skew. The difference between any two chronologically recorded time values returned from the now method MUST never be negative." Not normative for our usage, but might surprise some.

Both of these are troublesome given that they don't seem to admit of an implementation that uses the system clock's idea of time relative to Jan 1, 1970.
We can do it, but it's a novel usage of the type."


[BA] Looking at the WebRTC 1.0 specification, DOMHiResTimeStamp is used in the Stats API.  For example:  

dictionary RTCStats {
             DOMHiResTimeStamp timestamp;
             RTCStatsType      type;
             DOMString         id;
};

Should we file an Issue on this?

Received on Monday, 21 September 2015 18:50:51 UTC