W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2009

Re: DOMTimeStamp interface not defined in L3 events...

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Mon, 05 Oct 2009 12:10:11 +0300
Message-ID: <4AC9B7F3.3030008@helsinki.fi>
To: Jonas Sicking <jonas@sicking.cc>
CC: Boris Zbarsky <bzbarsky@mit.edu>, Jacob Rossi <rossi@gatech.edu>, www-dom@w3.org, travil@microsoft.com
On 10/5/09 10:06 AM, Jonas Sicking wrote:
> On Sun, Oct 4, 2009 at 1:20 PM, Boris Zbarsky<bzbarsky@mit.edu>  wrote:
>> Jacob Rossi wrote:
>>> Doesn't work for me. Test page:
>>> http://www.jacobrossi.com/eventdates.html
>>> In Firefox,
>> Oh, boy.  There are at least two separate things going on here:
>> 1)  Gecko is not internally consistent.  Sometimes its event timestamps are
>> microseconds since the UNIX epoch (or at least sort of; this uses the
>> computer's internal clock), sometimes they're ticks since some arbitrary
>> (but consistent for a browser run, more or less) point in time.  The tick
>> interval is a millisecond in some cases but not others; it's OS-dependent
>> (and never smaller than 10 microseconds or larger than 1 millisecond).  A
>> complete mess, all in all.
>> 2)  The actual treatment of event.timestamp is DOM2 Events is pretty
>> underdefined (though not to the point of allowing all of the above mess).
>>   It specifies that the timestamp is "milleseconds relative to the epoch" but
>> then clearly goes on to say: "Examples of epoch time are the time of the
>> system start or 0:0:0 UTC 1st January 1970."
>> Presumably the latter part is fixable as part of a spec (define the epoch to
>> be the UNIX epoch).  The former part just needs to be fixed in Gecko.  See
>> https://bugzilla.mozilla.org/show_bug.cgi?id=77992 and
>> https://bugzilla.mozilla.org/show_bug.cgi?id=323039 for the relevant bugs.
>>> The value of e.timeStamp *looks* like a UNIX timestamp (milliseconds
>>> since Jan. 1, 1970 midnight), which is what MDC documentation led me
>>> to believe it should be.
>> The MDC documentation has a certain tencency to be based on the DOM specs.
>>   :(
>>> I think using a JS date object makes the most sense (especially since
>>> it's easy to go from a date object to either a date/time string OR
>>> unix timestamp). But if there are sites that expect this to be unix
>>> timestamp or date string, then this would break them.
>> I would be very surprised if such sites exist, honestly, given the above
>> situation with Gecko.
> What is the use case for this feature?
This is indeed a good question

> It doesn't seem very hard to implement, but there's certainly a
> performance cost to getting the current time for each event.
It is always possible to implement the feature by returning 0.
Both D2E and D3E allow that.

Received on Monday, 5 October 2009 09:11:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:15 UTC