- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Mon, 05 Oct 2009 12:10:11 +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 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. Olli
Received on Monday, 5 October 2009 09:11:00 UTC