Re: [LEAPSECS] Comparing Time Scales

From: Warner Losh <imp_at_BSDIMP.COM>
Date: Fri, 03 Feb 2006 21:59:05 -0700 (MST)

From: James Maynard <james.h.maynard_at_usa.net>
Subject: Re: [LEAPSECS] Comparing Time Scales
Date: Fri, 03 Feb 2006 17:31:46 -0800

> Warner Losh wrote:
> > From: James Maynard <james.h.maynard_at_usa.net>
> > Subject: Re: [LEAPSECS]Comparing Time Scales
> > Date: Fri, 03 Feb 2006 15:37:40 -0800
> >
> >
> >>Thanks, guys, for your feedback. Here's another iteration.
> >>
> >>The numbering of NTP seconds in the vicinity of a leap second seems to
> >>differ from one document to another. Here I follow the NTP (version 3)
> >>specification, RFC 1305, in which the Leap Indicator (sys.leap,
> >>peer.leap, pkt.leap) is 01 if a positive leap second is to occur at the
> >>end of the current UTC day, and 00 if no leap second is pending.
> >>
> >>UTC = 2005-12-31 23:59:59, NTP seconds = 3 345 062 399, LS_pending = 01
> >>UTC = 2005-12-31 23:59:60, NTP seconds = 3 345 062 400, LS_pending = 01
> >>UTC = 2006-01-01 00:00:00, NTP seconds = 3 345 062 400, LS_pending = 00
> >
> >
> > If you read different documents carefully, you'll see this sequence:
> >
> > UTC = 2005-12-31 23:59:60.0, NTP seconds = 3 345 062 400.0, LS_pending = 01
> > UTC = 2005-12-31 23:59:60.5, NTP seconds = 3 345 062 399.5, LS_pending = 01
> > UTC = 2006-01-01 00:00:00.0, NTP seconds = 3 345 062 400.0, LS_pending = 00
> >
> > Where the 399 second repeats. The documents say that just after time
> > is incremented to 400, the last second of the day is repeated....
> >
> > Warner
> >
>
> This looks like something that needs to be resolved in a standards
> committee, such as David Mills' working group on Version 4 of the NTP
> protocol. Meanwhile, you have to cope with different implementations
> that do it different ways!

I know that various ntp implementations behave exactly as I describe.
They repeat the last second of the day. I believe this is the correct
behavior, and have made sure that FreeBSD behaves this way.

> If a device has leap second information available to it at all, it
> should know at least an hour ahead of time that a positive leap second
> is pending. Given that information, it should be able to arm itself for
> the upcoming leap second. Once in "armed for leap second state," each
> NTP server and client would count the one-second epochs in the last
> 61-second minute of the day, assigning NTP second numbers "correctly"
> and displaying (if it has a display) the UTC time correctly. (Of course,
> I think the method shown in my table should be the standard way of
> assigning NTP second numbers. But that would be a matter for the
> standards committee to resolve.)
>
> So I *think* my table shows how the leap second *should* be handled on
> the various time scales listed in the table. There remains the standards
> effort -- electropolitical engineering -- of reaching agreement on an
> unambiguous standard to describe how leap seconds should be handled.

The problem is that your results give a second that's in the wrong
day. The leap second is added to the end of the day, not the
beginning of the day. You don't repeat the first second of the day
twice. That poses real problems for things like cron that might start
things twice at midnight.

Also, most ntp implemenations in the host have more than just
pending/not-pending. They have a stat that's 'leap second executing'
which is part of the standard ntp_adjtime info returned.

Warner
Received on Fri Feb 03 2006 - 21:00:25 PST