RE: Potential Issue with DONHiResTimeStamp in WebRTC Stats API

Submitted as Issue #309:
https://github.com/w3c/webrtc-pc/issues/309


From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Monday, September 21, 2015 1:26 PM
To: Bernard Aboba <Bernard.Aboba@microsoft.com>; public-webrtc@w3.org
Subject: RE: Potential Issue with DONHiResTimeStamp in WebRTC Stats API

Yes, we should. At the very least, it must be clear.
Den 21. september 2015 20:50:10 CEST, skrev Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>>:

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?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.