W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] Proposal: Event.creationTime

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 6 May 2014 23:00:07 -0700
Message-ID: <CAJE5ia8ZcJTcd+6-bRjC-gG2bS6dEbtk=Wz5DKOUNYQ0toL_yA@mail.gmail.com>
To: Brian Birtles <bbirtles@mozilla.com>
Cc: whatwg <whatwg@lists.whatwg.org>
Can we just change timeStamp to be a DOMHighResTimeStamp rather than
introducing a redundant property?

Adam



On Tue, May 6, 2014 at 10:51 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> 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 06:01:04 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC