Subject: Re: Time-stamp server. TimePrecision info

From: "Todd S. Glassey" <[email-masked]>
Date: Tue, 30 Mar 1999 19:44:40 -0800

How will you deal with leap seconds?

T.

-----Original Message-----
From: Paul Koning <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Tuesday, March 30, 1999 10:26 AM
Subject: RE: Time-stamp server. TimePrecision info

>>>>>> "Robert" == Robert Zuccherato <[email-masked]> writes:
>
> Robert> Personally, I have no problem with adding an optional
> Robert> timePrecision field to specify the accuracy of the given time
> Robert> stamp. ...
>
> >> ---------- From: Michael Zolotarev
> >> ...we should
> >> think in terms of what a user would NEED to know. After all, what
> >> matters for a client is 1) how trustworthy is the TSA in general,
> >> and 2) how accurate is the time in that particular time stamp.
> >>
> >> Presenting a customer with extra details, like splitting the
> >> quality of the time into its precision and accuracy, may
> >> unnecessarily overcomplicate the
> >> issue, without giving much information anyway.
>
>These sound like good things.  If they are done, though, it would be
>very helpful if ambiguous words like "precision" and "accuracy" are
>avoided (and in particular, not used as terms intended to describe
>*different* things).  What is needed are descriptions of what a
>parameter tells you, e.g.,
>
>a. the smallest representable increment in the timestamp (often called
>"resolution")
>
>b. the bound on the difference between the timestamp value and the
>current UTC ("accuracy"?  "precision"?)
>
>c. whether the timestamp is monotonic (or possibly, if non-monotonic,
>the bound on its nonmonotonicity).
>
>Obviously, a < b, and if c != 0, a < c < b.  b is the hardest to
>supply, but also the one that's essential if you want to draw
>conclusions from timestamps generated by two servers.
>
> paul
>

---

From: Paul Koning <[email-masked]>
Date: Wed, 31 Mar 1999 13:02:39 -0500

>>>>> "Todd" == Todd S Glassey <[email-masked]> writes:

 Todd> How will you deal with leap seconds?  T.

The NTP RFC (RFC 1305) has an excellent discussion on this and the
approaches it describes would be good to use.  In particular, it
suggests using a two part date/time coding (day separate from
time-in-day).  That way the existence of leap seconds merely increases 
the range of the second field by one.  (Analogy: if you sent the
timestamp as yyyymmddhhmmss.ssss the impact is merely that ss can be
from 0 to 60, not 0 to 59.)

	paul

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 31 Mar 1999 10:30:38 -0800

>How will you deal with leap seconds?

The only solution I can think of would be UGLY, but would preserve
the all-important monotonicity.  At least it would work when a
leap-second is added. (Subtracting is another matter.  You would
already have monotonicity, but differencing might be difficult.) 

Add another field to the "seconds", as little as one "bit", that
is always zero except for a leap-second, when it is "one."

  E.G.   leap.seconds.milliseconds

Now, if (say) the 23rd second of this minute had to be "repeated"
(the clock is being set back 1 second, "gaining" a leap second,)
then it would first occur as 0.23.ms, and then a second later
as 1.23.ms.

Thus, the sequence of timestamps of seconds from 21 to 25 might
be recorded as 0.21, 0.22, 0.23, 1.23, 0.24, 0.25, with

    0.23 < 1.23, and 1.23 < 0.24

Losing a leap-second (should that ever happen) is another matter.
One could just drop the "missing" second as the clock advances.
E.G.

    0.21, 0.22, 0.24, 0.25

Monotonicity is preserved.  Differencing is a headache.

I wonder how they will actually deal with this.

___tony___

Tony Bartoletti                                             LL
Center for Information Operations and Assurance          LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 303                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8002               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL