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 11:07:37 -0700
Message-ID: <63df84f0910051107l89606baqe99bd01453c3b848@mail.gmail.com>
To: Olli@pettay.fi
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Jacob Rossi <rossi@gatech.edu>, www-dom@w3.org, travil@microsoft.com
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. 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
Received on Monday, 5 October 2009 18:08:30 GMT

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