[whatwg] Proposal: Event.creationTime

Hi,

Gecko's implementation of Event.timeStamp does not conform to the 
spec[1] since it reports the number of milliseconds since system start 
rather than 00:00:00 UTC on 1 January 1970. This is tracked as Mozilla 
bug 77992 [2]. DOM Level 2 allowed this[3] but the spec has since changed.

One reason for not updating to match the spec has been concern about 
using a non-monotonic clock as a time source. This can lead to bugs when 
the system clock is adjusted.

Now that we have a DOMHighResTimeStamp that provides a monotonically 
increasing time, I propose we add it to the Event interface.[4]

This time is measured from navigationStart which removes some of the 
security concerns raised regarding using system start.[5] 
navigationStart is also the point of reference being using for 
Performance.now(), requestAnimationFrame and Web Animations.

As for use cases for event timestamps, apparently Youtube uses the 
timeStamp on progress events to estimate download bandwidth. Another use 
case is that of SMIL which seems to want to overload the timestamp from 
being strictly creation time to when the event *should* have been 
created in order to avoid synchronization slew.[6]

Proposal:

   partial interface Event {
     readonly attribute DOMHighResTimeStamp creationTime;
   };

(Alternative naming suggestions are obviously most welcome.)

Semantics are as with 'timeStamp' but based on navigationStart.

Given that 'timeStamp' is currently implemented inconsistently, it might 
be possible to eventually deprecate it.

Best regards,

Brian

[1] http://dom.spec.whatwg.org/#dom-event-timestamp
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=77992
[3] 
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-timeStamp
[4] http://www.w3.org/TR/hr-time/
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=579652#c2
[6] http://www.w3.org/TR/SMIL/smil-timing.html#q135

Received on Wednesday, 7 May 2014 05:52:01 UTC