- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Mon, 05 Oct 2009 22:29:48 +0300
- 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 UTC