RE: Time in DOM 2 Events

Hi David -

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

This is orthogonal - I am just looking for a value in the same nominal
range.

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

I did not mean that DOM would do any of this, just that we have a consistent
epoch definition. For my applications, the timestamp is used for scheduling,
and can be predelivered (eliminating issues of skew, etc.). It simplifies
things if everyone is talking the same nominal range.

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

As others have noted, we can afford 64 bits. Rollover is even worse than
translation.

Patrick

Received on Monday, 7 February 2000 13:19:27 UTC