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 22:29:48 +0300
Message-ID: <4ACA492C.3050800@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 9:07 PM, Jonas Sicking wrote:
> On Mon, Oct 5, 2009 at 2:10 AM, Olli Pettay<Olli.Pettay@helsinki.fi>  wrote:
>> 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.
> That seems very strange to me.
Yeah, that is very strange.

  Optional features don't really have a
> good track record. Is there a reason to believe that sites won't
> depend on this feature if it's available in one or two popular
> browsers? Unless the feature is so useless that no-one will use it,
> but in that case it seems better to just remove it.
> / Jonas
A real usecase for timestamps would be great.
Otherwise we could deprecate them and browsers could make .timeStamp
no-op which has always value 0.

Received on Monday, 5 October 2009 19:30:28 UTC

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