- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 5 Oct 2009 11:07:37 -0700
- 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 UTC