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]


  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,


[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

Reply via email to