> -----Original Message----- > From: Pablo Garaizar Sagarminaga [mailto:garai...@deusto.es] > > Hello, > > on Fri, 25 May 2012 16:49:25 -0700 Jonas Sicking <jo...@sicking.cc> > wrote: > > > > This is not yet an official last call, but if you'd like to re-read > > > the spec and provide additional feedback--this is a good time to do > > > it. > > Disclaimer: I don't know how and where to do this proposal. I hope you'll help > me to find the proper place to send it. > > During High Resolution Time working draft final call for public comments I > wrote a suggestion about DOM events' timestamps and the use of > monotonically increasing values provided by High Resolution Time > API: > > I would love to have the chance to get a DOMHighResTimeStamp as a property > of an DOM event, like event.timeStamp. Events' > timestamps are also subject to system clock skew and other problems > mentioned in High Resolution Time working draft, and providing access to HRT > when triggering events will be very helpful to program accurate interactions. > > I'm not sure if this could be done adding a new property to the event > interface > (e.g., HRTimeStamp) or modifying the typedef of the current timeStamp > property (i.e., DOMHighResTimeStamp). > > It would be great to discuss this feature in future versions of the drafts > mentioned before.
I discussed this briefly with Jatinder Mann (who works on the High resolution timing spec--you might know him?). Based on that discussion it sounds like the high-resolution timestamp provides three features: 1. The timestamp is relative to the loaded page (not the Unix epoch) 2. The timestamp can be in microsecond resolution (a best effort-approach) 3. The timestamp is garuanteed to be monotonically increasing. Based on #1, we can't simply replace the current timestamp property on DOM events with a high-resolution time stamp--this would be a change (though perhaps not very impactful) to backward compatibility. Therefore, the only plausible action could be a new property (e.g., "highResolutionTimeStamp" or similar). However, I wonder what real value this would have. Typically events only fire within the scope of the current window and do not bleed out into other windows (Message and Storage events are notable exceptions)--so new Date() should be self-consistent (coming from the same script engine) even if other script engines are suffering from clock-skew. One issue that is present in IE, is Date objects that get serialized over from Web Workers--they can have a pretty big clock skew pretty quickly, but hypothetically performance.now() can cover those scenarios. Are there other specific use cases that you're finding where the timestamp property doesn't meet your needs?
