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>:
>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.