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