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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 5 Oct 2009 00:06:45 -0700
Message-ID: <63df84f0910050006s50974edfpb5799f9df969490@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Jacob Rossi <rossi@gatech.edu>, www-dom@w3.org, travil@microsoft.com
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?

It doesn't seem very hard to implement, but there's certainly a
performance cost to getting the current time for each event.

/ Jonas
Received on Monday, 5 October 2009 07:07:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT