This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 21911 - MediaPlaybackQuality.creationDate should be a DOMHighResTimeStamp
Summary: MediaPlaybackQuality.creationDate should be a DOMHighResTimeStamp
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Media Source Extensions (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-02 18:06 UTC by Andrew Scherkus
Modified: 2013-05-14 10:26 UTC (History)
4 users (show)

See Also:

Attachments

Description Andrew Scherkus 2013-05-02 18:06:04 UTC 
Date() is suspect to changes in system clock and/or clock skew. The High Resolution Time spec [1] provides a monotonically increasing, sub-millisecond API as well as new type DOMHighResTimeStamp (which is really just a double).

Given the performance-y nature of these stats, perhaps creationDate can be similar to window.performance.now() in that it's a time value measured relative to navigationStart [2].

[1] http://www.w3.org/TR/hr-time/
[2] https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#dom-performancetiming-navigationstart
Comment 1 Aaron Colwell 2013-05-02 21:16:03 UTC 
This seems reasonable to me.

Adrian: Do you have any reason to prefer Date() over DOMHighResTimeStamp?

If we change the type here then we should probably rename the attribute to creationTime.
Comment 2 Adrian Bateman [MSFT] 2013-05-06 17:34:11 UTC 
(In reply to comment #1)
> Adrian: Do you have any reason to prefer Date() over DOMHighResTimeStamp?

I'm fine with the change.
Comment 3 Aaron Colwell 2013-05-06 21:59:20 UTC 
Changes committed.
https://dvcs.w3.org/hg/html-media/rev/9ff5e42736b6