DOMTimeStamp interface not defined in L3 events...

> Annevk wrote:
> > I believe last time we looked into this it was figured out we could not
> > change it to a Date object. I wish we could, but there is probably too
> > much content out there using it in this way already.
>
> It probably does have to stay the say it is for backwards
> compatibility. But it sure would be nice to be able to do something
> like:
>
> var jsdate = e.timeStamp.toDate();

> On Sat, 3 Oct 2009, Jacob Rossi wrote:
>> Annevk wrote:
>> > I believe last time we looked into this it was figured out we could not
>> > change it to a Date object. I wish we could, but there is probably too
>> > much content out there using it in this way already.
>>
>> It probably does have to stay the say it is for backwards
>> compatibility. But it sure would be nice to be able to do something
>> like:
>>
>> var jsdate = e.timeStamp.toDate();
>
> Can't you do
>
>  var jsdate = new Date(e.timeStamp);
>
> ...? (Might need a factor of 1000 multiplier.)
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

>> Can't you do
>>
>>   var jsdate = new Date(e.timeStamp);
>>
>> ...? (Might need a factor of 1000 multiplier.)
>
> Doesn't work for me. Test page:   http://www.jacobrossi.com/eventdates.html
>
> In Firefox,
> 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. However, it's not a correct timestamp and is
> not off by a simple factor of 1000 or something.

>
> --Jacob
>
>
>
> On Sat, Oct 3, 2009 at 10:03 PM, Ian Hickson<ian@...>  wrote:
>> On Sat, 3 Oct 2009, Jacob Rossi wrote:
>>> Annevk wrote:
>>>> I believe last time we looked into this it was figured out we could not
>>>> change it to a Date object. I wish we could, but there is probably too
>>>> much content out there using it in this way already.
>>>
>>> It probably does have to stay the say it is for backwards
>>> compatibility. But it sure would be nice to be able to do something
>>> like:
>>>
>>> var jsdate = e.timeStamp.toDate();
>>
>> Can't you do
>>
>>   var jsdate = new Date(e.timeStamp);
>>
>> ...? (Might need a factor of 1000 multiplier.)
>>
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>>
>
>

> >
> > Can't you do
> >
> >  var jsdate = new Date(e.timeStamp);
> >
> > ...? (Might need a factor of 1000 multiplier.)
>
> Doesn't work for me. Test page:   http://www.jacobrossi.com/eventdates.html
>
> In Firefox,
> 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. However, it's not a correct timestamp and is
> not off by a simple factor of 1000 or something. Further, trying to
> convert an example of a HTML5 "valid date and time string" using the
> date.parse does not work.

> On Sun, 4 Oct 2009, Jacob Rossi wrote:
>> >
>> > Can't you do
>> >
>> >  var jsdate = new Date(e.timeStamp);
>> >
>> > ...? (Might need a factor of 1000 multiplier.)
>>
>> Doesn't work for me. Test page:   http://www.jacobrossi.com/eventdates.html
>>
>> In Firefox,
>> 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. However, it's not a correct timestamp and is
>> not off by a simple factor of 1000 or something. Further, trying to
>> convert an example of a HTML5 "valid date and time string" using the
>> date.parse does not work.
>
> Ah, in Firefox, at least on Mac, it's the number of milliseconds since the
> computer was last restarted.
>
> The above works in Safari.
>
>
>> 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.
>
> Well it depends what the use case is. If the use case is just to be able
> to tell the relative time between events, Firefox's behaviour is fine. Why
> do you want Date objects?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

> 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.

> On Sun, Oct 4, 2009 at 1:20 PM, Boris Zbarsky<bzbarsky@...>  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?

> On 10/5/09 10:06 AM, Jonas Sicking wrote:
>>
>> On Sun, Oct 4, 2009 at 1:20 PM, Boris Zbarsky<bzbarsky@...>  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.

> On Mon, Oct 5, 2009 at 2:10 AM, Olli Pettay<Olli.Pettay@...>  wrote:
>> On 10/5/09 10:06 AM, Jonas Sicking wrote:
>>>
>>> On Sun, Oct 4, 2009 at 1:20 PM, Boris Zbarsky<bzbarsky@...>    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
>>
>>
> 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.