Re: Time in DOM 2 Events

Patrick Schmitz wrote:
> 
> 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.

Not unless there's also elimination of clock skew, which would mean
also depending on some additional protocol like NTP.

But I was unaware that anyone was really proposing that DOM would be
the wire protocol in such a case.  I never understood that to be a
design goal, and never heard protocol considerations (like minimizing
round trips) raised.  The natural way to use DOM in such distributed
apps would be as an API used to mediate access to some other protocol,
which supported caching, synchronized updates, and so on.  That lower
protocol layer would address whatever level of clock synch is necessary,
and perhaps add a constant to use the appropriate epoch.
 

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

It's always nice to avoid translations.  Do I take it you have no problem
with the epoch starting 1970-01-01T00:00:00 UTC then?  Or would you maybe
prefer to take the approach IP took, and just say "milliseconds since
midnight UTC" and force apps to deal the with rollover?

- Dave

Received on Thursday, 3 February 2000 11:15:08 UTC