ISSUE-172: Fix Event.timeStamp

Event.timeStamp

Fix Event.timeStamp

State:

CLOSED

Product:

HISTORICAL: DOM3 Events [All Bugs and Issues use Bugzilla: http://tinyurl.com/Bugs-DOM3Events]

Raised by:

Doug Schepers

Opened on:

2010-10-20

Description:

Cameron McCormack <http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0069.html>:
[[

The definition of Event.timeStamp is currently:

Used to specify the time at which the event was created in
milliseconds relative to 1970-01-01T00:00:00Z. Due to the fact that
some systems may not provide this information the value of timeStamp
may be not available for all events. When not available, the value
shall be 0.

I think we should remove the allowance for implementations to have
Event.timeStamp be 0. It might be that implementations are running on
systems that don’t know what the actual time is, but surely JS Date is
returning something; I think it would be fine for those implementations
to assume a particular time on startup, for example.

I don’t think we need to worry about implementations that can’t even
track the progress of time.

I also think we should make Event.timeStamp be not the time at which the
event was created (the construction of the Event object?) but the time
at which the event represented by the Event object occurred. For user
created events, we could have it be either the time that createEvent()
is called or the time that initEvent() is called (since timeStamp is
read only).
]]

Boris Zbarsky <http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0070.html>:
[[
On 10/18/10 10:41 PM, Cameron McCormack wrote:
> I also think we should make Event.timeStamp be not the time at which the
> event was created (the construction of the Event object?) but the time
> at which the event represented by the Event object occurred.

This is particularly relevant to situations in which the event is
_about_ to occur and the UA wants to notify scripts of this. While it
can only guess at when the event will really occur (since the scripts
could take a while), that still seems more useful than reporting some
time in the past that has nothing to do with the event in question.

We (Mozilla) actually ran into this with MozBeforePaint events. For now
we're having the timeStamp on those represent the time when the paint is
conceptually happening (i.e. the sampling time that will be used for
animations when the paint happens).
]]


Boris Zbarsky <http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0071.html>:
[[
Speaking of which, I'm actually not crazy about event.timeStamp
being in milliseconds since the Epoch. The times that operating
systems report on events (like key events and mouse events) are, for
at least some systems, I think, based on an interval timer -- a
separate timer from the clock. (I think (hope) that it's not
particularly related to the clock, and doesn't, for example, go
backwards if the clock is changed or adjusted by NTP. I don't
really know the details. At the very least, events from GDK are
documented to be in milliseconds (and are), and definitely aren't in
milliseconds since the epoch; those are the values that Gecko on
Linux reports for timeStamp.)

I think interval timer times are quite useful. I'd like to be able
to have APIs that let Web pages do things like start animations
based on the time of the mouse or key event that triggered them,
which I think should make them appear more responsive, even if it
really takes them a little time to get started.

If we have to report a time in milliseconds since the epoch, we'd be
unlikely to be able to correctly report the time the key was
pressed; we'd have to report the time Gecko processed the key event,
which might be a bit later.
]]

Related Actions Items:

No related actions

Related emails:

1. ISSUE-171 and ISSUE-172 (from Jacob.Rossi@microsoft.com on 2011-07-29)
2. Re: ISSUE-172 (Event.timeStamp): Fix Event.timeStamp [DOM3 Events] (from jrossi@microsoft.com on 2011-04-08)
3. Re: publish a new Working Draft of DOM Core; comment deadline March 2 (from annevk@opera.com on 2011-02-25)
4. Re: publish a new Working Draft of DOM Core; comment deadline March 2 (from schepers@w3.org on 2011-02-24)
5. Re: publish a new Working Draft of DOM Core; comment deadline March 2 (from annevk@opera.com on 2011-02-24)
6. RE: publish a new Working Draft of DOM Core; comment deadline March 2 (from adrianba@microsoft.com on 2011-02-24)
7. Minutes: DOM3 Events Telcon, 27 October 2010 (from schepers@w3.org on 2010-10-29)
8. ISSUE-172 (Event.timeStamp): Fix Event.timeStamp [DOM3 Events] (from sysbot+tracker@w3.org on 2010-10-20)

Related notes:

Display change log