RE: Time in DOM 2 Events

For most applications, local start of epoch is fine.  Nevertheless, for
distributed apps (e.g. coordinated display of document sets; events that
will be delivered in a media stream with delivery timestamps), a common
epoch would really help.  There are certainly other hurdles for both
examples I mention, but it would be nice to not have to translate epochs if
and when such xplat issues arise.

Thanks - Patrick


> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Monday, January 31, 2000 9:27 AM
> To: John Cowan
> Cc: Patrick Schmitz; www-dom@w3.org
> Subject: Re: Time in DOM 2 Events
> 
> 
> John Cowan wrote:
> > 
> > Patrick Schmitz wrote:
> > 
> > > I cannot believe that I missed this in earlier reviews, 
> but the Event
> > > interface in  DOM 2 Events is missing a timestamp for the 
> event.  Without
> > > this, many common UI functions (like filtering small 
> motions between click
> > > down and click up) will be hard or impossible to do well. 
> In addition, for
> > > SMIL Boston to work with DOM Events, we would have to 
> define a parallel set
> > > of Event interfaces that add the time.  This would be a 
> royal pain.
> > 
> > An excellent point.
> > 
> > I propose Java-compatible timestamps: the number of 
> milliseconds since
> > 1970-01-01T00:00:00 UTC, expressed as a 64-bit integer.
> 
> I applaud the sentiment ... ;-)
> 
> However, if there's an issue with that "start of epoch" date, it
> may be OK to have it be unspecified ... since the motivation is
> to detect relative times.  Individual hosting environments would
> specify their start-of-epoch date.
> 
> A 64-bit millisecond timestamp seems the right model to me.  Apps
> won't have to worry about it rolling over, yet the events (UI only!)
> will be easily distinguished.
> 
> - Dave
>

Received on Wednesday, 2 February 2000 19:37:30 UTC