[ntp:hackers] Leap second list file

Warner Losh imp at bsdimp.com
Mon Jan 16 21:19:45 UTC 2012


On Jan 16, 2012, at 1:50 PM, Danny Mayer wrote:

> On 1/16/2012 3:02 AM, Dave Hart wrote:
>> On Mon, Jan 16, 2012 at 02:30, Danny Mayer <mayer at ntp.org> wrote:
>>> On 1/15/2012 3:17 PM, Warner Losh wrote:
>>>> Also, it is only 'leap second at the end of today' nor 'leap second at end of the month'
>>> 
>>> No, that's not what it says. See below:
>>> 
>>> LI Leap Indicator (leap): 2-bit integer warning of an impending leap
>>>  second to be inserted or deleted in the last minute of the current
>>>  month with values defined in Figure 9.
>> 
>> You're both right.  Leap-add and leap-del LI values do indicate a leap
>> second at the end of the current month, on ntpd's input path.
>> However, in deciding whether to indicate a known upcoming leap second
>> (however known) to downstream clients, ntpd will not indicate a
>> pending leap second in LI until less than one day remains to the
>> scheduled insertion/deletion.  So in practice, LI means both at the
>> end of this UTC month at the end of today UTC.
>> 
>> Unless you're using the ACTS modem refclock with a poll interval
>> greater than 24h, a day is plenty of notice for the software to do its
>> job, though some human operators might appreciate the opportunity to
>> notice it sooner.  Given those two factors, I wonder if ntpd should be
>> changed to indicate pending leap seconds earlier, perhaps after the
>> first hour of the month to guard against accidentally misfiring the
>> change a month early.
> 
> If the reference implementation is not indicating a leap second from the
> beginning of the month I would argue that it is not following the RFC.
> The leap second should be indicated as soon as possible in the UTC month
> that it is aware that it should take this action. The wording in the RFC
> may not be strong enough but I believe that that is the intent.

The RFC doesn't say this.  It says that when it is set, it means that there's a leap second at the end of this month.  It doesn't say that an implementation MUST set this flag on the first day of the month and maintain it for the entire month.  This intent would be said with language like:

	The LI bit SHALL be set as early in the month as is practicable.

which seems to be missing from the standard.  Even with the above language, the current behavior would be conforming.  Only of there's language like

	The LI bit MUST be set for the entire month...

would it be non-conforming.  And even then not all reference clocks produce the warning soon enough.  IRIG being the worst, since it only has an indication that the current minute (or is that hour) will have an extra second.

"Be conservative in what you generate, and liberal in what you accept"

Warner


More information about the hackers mailing list