Re: [LEAPSECS] Ambiguous NTP timestamps near leap second

From: Rob Seaman <seaman_at_noao.edu>
Date: Thu, 16 Feb 2006 13:28:34 -0700

On Feb 16, 2006, at 12:12 PM, Markus Kuhn wrote:

> No reply from an NTP server shall ever represent any point in time
> between 23:59:60 and 24:00:00 of a UTC day. If a client requests an
> NTP timestamp and the response would represent a point in time
> during
> an inserted leap second, then this request shall be ignored.

I don't really have a dog in this race. The proposed fix sounds
quite reasonable. I merely want to point out that sexigesimal
notation is more forgiving than some messages on this list might
suggest. I believe I previously mentioned that the image processing
software we distribute to the astronomical community interprets a
sexigesimal number as a floating point representation of hours, e.g.,
23:30:00 ~= 23.5 hours. (One could alternately argue for an
interpretation as a fraction of a day, something like 12:00:00 ~= 0.5
days.)

The point under this interpretation is that it is completely legal
for each of the colon delimited fields to exceed 24 hours or 60
minutes or 60 seconds:

        = 123:544:99.2222
        132.09422838889

and, of course:

        = 23:59:60
        24.

We also have a %h printf format that inverts the process and enforces
more familiar rules:

        printf ("%h\n", 23:59:60)
        24:00:00.0

        printf ("%h\n", 123:544:99.2222)
        132:05:39.2

(Normal floating point precision issues apply, of course.) Note also
that the values are not expressed as string literals.

This is not a unique usage. Used to have a Casio (?) calculator that
could similarly process such values as fractions. And our microwave
is surely not unique in permitting times to be entered as arbitrary
numbers of minutes and arbitrary numbers of seconds.

For this discussion, we really only have to exclude the range
23:59:60-24:00:00 (and only during leap second events). A value
larger than 24:00:00 can be handled consistently by interpreting it
as so many seconds into the next day. What we're really excluding is
the range 86400-86401 seconds from the start of the day in question,
no matter how that time interval is expressed.

In fact, to simplify coding, simply reject all requests received
between 23:59:00 and 24:01:00. Unlikely this would have any more
significant effect in practice.

Or, of course, better yet - why don't we try it and see if it works
rather than speculating.

Rob Seaman
NOAO
Received on Thu Feb 16 2006 - 12:28:59 PST