Re: DOMHighResTimeStamps in DOM events, use cases

I think we will need a new property. Although I would also prefer changing
Event.timeStamp to be Performance timestamps, it seems that the only way to
check if it was safe to compare it with Date.now() or Performance.now()
would be to check the magnitude of the timestamp. I like Event.systemTime
as well.


On Tue, Oct 9, 2012 at 10:28 AM, Pablo Garaizar Sagarminaga <
garaizar@deusto.es> wrote:

> On Tue, 9 Oct 2012 16:02:21 +0200
> Anne van Kesteren <annevk@annevk.nl> wrote:
>
> > > Would it break too much to simply update timeStamp and make it work
> > > like this? And have it return DOMHighResTimeStamp?
>
> I agree with Anne that current Event.timeStamp is very similar to
> calling to Date.now() at the beginning of the event callback, so it
> could be replaced by the new high-resolution timestamp without
> functionality loss.
>
> But I am not sure whether changing the type and behaviour of a property
> at the same time is a good idea or not.
>
> > FWIW, if it turns out we are stuck with both, a better name than
> > hRTimeStamp would be appreciated. Some ideas: Event.time,
> > Event.systemTime, Event.originalTime, Event.platformTime... I like
> > none of them and would prefer fixing Event.timeStamp.
>
> Event.systemTime sounds good to me :-)
>
> Some other ideas: Event.start, Event.startTime, Event.triggerTime...
>
> --
>   Pablo Garaizar Sagarminaga
>   Universidad de Deusto
>   Avda. de las Universidades 24
>   48007 Bilbao - Spain
>
>   Phone:       +34-94-4139000 Ext 2512
>   Fax:                  +34-94-4139101
>