Re: DOMTimeStamp interface not defined in L3 events...

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.

-Boris

Received on Sunday, 4 October 2009 20:20:51 UTC