Subject: TSTTime definition

From: Denis Pinkas <[email-masked]>
Date: Thu, 05 Aug 1999 13:34:16 +0200

After looking at the thread here is the position, as I see it.

I got a nice proposal from Stefan Santesson saying the serialNumber
in TSTInfo could be made mandatory without any problem in case of a
crash to remember the last one sent. The solution is fairly simple:
derive the serialNumber from the time through a proprietary
algorithm making sure that the integer obtained is always bigger if
the time is superior. The only drawback (that I am willing to
accept) is to use 64 bits integers. 

So let us assume that the serialNumber in TSTInfo is now mandatory.

We can then suppress the serialNumber in TSTTime.

Since many applications will only use a time with a precision of a
second , it makes sense to use GeneralizedTime only up to a
precision of a second.

Another argument is that using GeneralizedTime up to the
millisecond, would not satisfy some people wishing to go beyond the
millisecond.

So we need an *additional* information to go under the millisecond,
associated with a precision factor.

The current proposal is directly inspired from NTP. This should be
satisfactory. If not, I would like to see an agreement on an
alternative proposal written in ASN1 to specify only the time below
the second.

Of course, these additional fields will all be optional.

Denis

---

From: Paul Koning <[email-masked]>
Date: Thu, 5 Aug 1999 09:51:39 -0400

>>>>> "Denis" == Denis Pinkas <[email-masked]> writes:

 Denis> Since many applications will only use a time with a precision
 Denis> of a second , it makes sense to use GeneralizedTime only up to
 Denis> a precision of a second.

 Denis> Another argument is that using GeneralizedTime up to the
 Denis> millisecond, would not satisfy some people wishing to go
 Denis> beyond the millisecond.

 Denis> So we need an *additional* information to go under the
 Denis> millisecond, associated with a precision factor.

Why?  As I understand it, GeneralizedTime allows more than 3 digits
after the decimal point.  If you don't need them, don't look at them.
But I see no benefit in an arbitrary restriction that you must not go
beyond milliseconds.  Such a restriction modifies the standard
semantics of the datatype; it doesn't make any difference to an
application that only cares about seconds; and it introduces a problem 
for cases where you want better than milliseconds.  As Peter Gutmann
pointed out, why invent a new flat tire when an acceptable wheel
already exists?

	paul