This seems to work fine for me on Firefox 8, in that the timestamp is present and increases on each click. Which version are you using, and what values do you expect?

I also use FF8.

Timestamp jq 1.6.4: 1321090259864

Timestamp jq 1.7 (FF): 96653321

Timestamp jq 1.7 (Chrome): 1321090329822

Not enough digits in FF.

I have filed a bug with Firefox on this, let's see if they can fix it quickly.

https://bugzilla.mozilla.org/show_bug.cgi?id=702015

In the meantime, you can simply say "new Date()" in your event handler. That was taken out in 1.7 because it turned out to be an expensive operation to do by default when so few people need the value.

OK, well if you follow that link above it turns out my ticket is a dup of this circa-2004 bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=238041

The timestamp is being truncated. However, I am hesitant to simply go back to what we were doing before (assigning our own new Date in our handler) because it is wrong. The event.timestamp is supposed to be the time the event was created *in the browser*:

http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-event-type-timeStamp

Many milliseconds (or even seconds in the worst case) can go by before the event makes it to jQuery where we would timestamp it with our fake stamp. If someone just needs to know what time it is at the point their own code is running, they can do their own new Date(). If, however, they need to know when the event was created, then we're just papering over the problem, adding time to event setup, and lying about when the event was created.

Since anonymous reported this, I can't ask them about their particular application. Other feedback welcome, but at this point I'm not pegging it to a release until we know more about how that fix should look.

You are correct that it is better to follow the W3C specs, but jQuery already puts jQuery.now() in event.timeStamp when the event doesn't have a value for timeStamp, which is against the W3C specs. Therefore I do not think this is a proper reason for not setting the event.timeStamp to the value of new Date() in case of wrong data.

This bug is even worse in Opera 11.60. http://jsfiddle.net/YNAc6/ gives a negative value:

-2147483648

#11080 is a duplicate of this ticket.

@Cokegod, that was so triggered synthetic events would get a timestamp.

@kb, please report that bug to Opera.

I still believe the 1.6.4 behavior is incorrect; there is no reason to always stick new Date() into that field after the fact since you can easily get that time in your own event handler.

Does anyone have a resolution that will still make timeStamp useful for the purpose the W3C intended?

I posted #11080. Sorry for the duplicate. Two points:

1. It doesn't work at all in IE8 now (not sure about IE9), "undefined" being returned.

2. If one cannot make it work as per the W3C specs, for the reasons given above, then why not leave it as it was and not break backwards compatibility too?

What are you using this value for? If it is to get the *current* time then use new Date. If it is for some other purpose, please give us some more information.

It is to find the time that an event occured. For the reasons explained in comment 5, this is unlikely to be accurate so it is essentially returning the current time; so. for sure, I can alter my code to new Date and get the same thing.

However, the two points remain:

1. It is introducing unnecessary regressions. Some of these are fatal (e.g. on IE8).

2. The documentation is now not correct and developers will waste time trying to work out why their code doesn't work they way it is supposed to.

Can you clarify how this is fatal in IE8? As you say, the purpose of that field is to determine when the event occurred. On browsers that get it wrong, we cannot provide the information. All we can do is lie about it, which was what we did before 1.7. If we do that, you will never know whether the data in that field is correct or not.

#11362 is a duplicate of this ticket.

Now Opera and Firefox can have a contest to see who can fix this first. My money is on Opera.

Already fixed in Opera Next (Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; Edition Next; en) Presto/2.10.255 Version/12.00).

What do I win? :P

You win a happy tweet! Thanks again.

Lacking any compelling use cases for a fake timestamp, I'll close this and we can hope that Firefox will fix their bug at some point. I'm using cantfix since the only "fix" we could apply is to put the wrong value into timeStamp.

This doesn't seem to work in IE8, but works in IE9. Is there a need to put in a fix for IE8?

timestamp is not working in opera it return 0

Hi anonymouse,

Can you verify what version of Opera you're testing in? Versions < 12 have this bug, but it's been fixed for the next release.

Hi dmethvin,

Why did you close this bug?

event.timeStamp

also returns incorrect value in IE7 and IE8 (not test IE9), not only in FF.

It's closed cantfix because we can't fix it. We do not know when the browser queued the event for eventual delivery to JavaScript. If you have ideas on how to fix it please let us know.

Replying to [comment:25 dmethvin]:

It's closed cantfix because we can't fix it. We do not know when the browser queued the event for eventual delivery to JavaScript. If you have ideas on how to fix it please let us know.

I don't have any idea of why

event.timeStamp

returns incorrect value in FF, possibly it's a FF bug. But if

event.timeStamp

is

undefined

(IE7,8), it should be assigned to the time when jQuery Event object is created. Actually, you already do it in jQuery.Event constructor:

// Create a timestamp if incoming event doesn't have one
this.timeStamp = src && src.timeStamp || jQuery.now();

However, it is overwritten by jQuery.event.fix:

event = jQuery.Event( originalEvent );

for ( i = copy.length; i; ) {
	prop = copy[ --i ];
	event[ prop ] = originalEvent[ prop ];
}

Is it intended? if not so, please fix it. Thanks!

We add the time for synthetic events. They should be present for native events. Setting the current time in the jQuery event handler would not tell you when the event was queued. If that difference (queued time vs clock time) doesn't matter in your application, your event handler should just use new Date().getTime()