[time-nuts] Leap second to be introduced at midnight UTC December 31 this year

Martin Burnicki martin.burnicki at burnicki.net
Wed Jul 20 06:01:31 EDT 2016


Gary E. Miller wrote:
> Yo time-nuts at febo.com!
> 
> On Tue, 19 Jul 2016 23:18:18 -0700
> Hal Murray <hmurray at megapathdsl.net>, time-nuts at febo.com wrote:
> 
>> gem at rellim.com said:
>>>> In general there's a common belief that a leap second can only
>>>> occur at the end of June or December. This is false. Don't ever
>>>> hardcode this assumption.  
>>
>>> NTP Classic thinks otherwise:
>>> 	http://bugs.ntp.org/show_bug.cgi?id=3D1090   
>>
>> If you read the fine print in that bug, you will see that it's a work
>> around for a bug in the HP firmware that is the core of this
>> discussion.

If it's known that certain devices out there have a certain bug then
it's fine IMO to try to fix this in the device-specific part of the
code, i.e. in ntpd's particular refclock driver. As Hal has already
mentioned, I wouldn't consider the refclock driver as belonging to the
core functionality, just because it is part of the code tree.

> Yes, I know the problem being solved.  Like today, the leap second being
> broadcast sooner than ntpd expects, so it picks the wrong month.

If the NTP specs say a leap second pending flag must not be set earlier
than month or 1 day before the leap second occurs then the upstream
software should account for this, regardless whether it's an upstream
NTP server, or a refclock driver.

>From ntpd's point of view:

- If it receives a leap second announcement, in which case should the
announcement be accepted; in which cases (buggy upstream sources) rejected?

- When should ntpd start to pass a leap second pending flag on to its
clients?

- When should ntpd start to pass a leap second pending flag down to the
OS kernel, so that the kernel can handle the leap second?

If the leap second warning is passed too early then there's a good
chance for confusion. If ntpd already has a current leap second file
then it already knows about the upcoming leap second now, but it still
doesn't pass a leap second pending flag to its clients, or to the OS kernel.

Beside this there's still another point:

- What should ntpd do if there are different upstream sources which
disagree about an upcoming leap second?

In current ntpd versions:

- A leap second file has precedence unless it is outdated.

- If no valid leap second file is available then a leap second warning
from a refclock is accepted.

- If no valid leap second file is available then a leap second warning
from upstream NTP server is only accepted if a majority of servers
provide it.

>> I don't think there is anything in the core of ntpd that restricts
>> leap seconds to Jun/Dec.  If there was, it would have filtered out
>> the above problem.

There has been such a check before ntpd 4.2.6, but the code has been
removed in current versions.

> How about this:
> 
> ntpd/refclock_hpgps.c, line 544:
> 
>                     /* See http://bugs.ntp.org/1090
>                      * Ignore leap announcements unless June or December.
>                      * Better would be to use :GPSTime? to find the month,
>                      * but that seems too likely to introduce other bugs.
>                      */
>                     case '+':
>                         if ((month==6) || (month==12))
> 
> 
>> Things get interesting if you are shipping code today that will last
>> for 10 or 20 years.  My HP Z3801A has software dates from 1995 so 20
>> years isn't unreasonable.  Of course, they were retired from
>> commercial use a long time ago, so maybe it's OK if the firmware has
>> bugs.
> 
> 20 years?  My house is 40 years old.  In an IoT world people would like
> to not throw away capital equipment every decade.
> 
> But i'm prolly spitting into the wind...
> 
>> I don't know any software projects that handle this sort of thing
>> cleanly. (My exposure is limited.)
> 
> gpsd filters out all but June and December.  So sort of cleanly, but
> clearly work needed.  I notice ntpd also filters out leap warnings for
> the first short bit of the month.  That might be worth doing too.

On systems which support this (Linux, *BSD, etc.) ntpd just passes a
leap second pending flag to the kernel, and the kernel handles the leap
second. However, ntpd has to keep track of its internal leap second flag
which it sends out to the clients.

So only if it polls the kernel status *after* the leap second has
occurred and sees that the kernel's leap second flag has been cleared,
ntpd can clear its internal leap second flag which it sends to the clients.

So there's a chance that ntpd sends a leap second flag to client during
a short interval after the leap second until it has polled the kernel
status again and found that the leap second has passed by.

So if clients accept a leap second flag in advance then it's important
that there's some interval at the beginning of a month where they don't.

> If a giant asteroid hits earth, and we need a negative leap second in 
> March, there will be a lot of urgent patching to do.

Yes. Specifically, the German long wave transmitter doesn't have the
possibility to announce a *negative* leap second.

Martin



More information about the time-nuts mailing list