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.

-Olli
Received on Monday, 5 October 2009 19:30:28 GMT

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