[ntp:hackers] Leap second list file
imp at bsdimp.com
Mon Jan 16 17:24:37 UTC 2012
On Jan 16, 2012, at 5:03 AM, Mike S 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.
> 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.
> Since the only mention of LI timing in RFC 5905 refers to "current month," I'd think the reference implementation should act accordingly. Waiting until the last day (or last second, for that matter) may be pedantically correct, but since the purpose of the LI flag is to provide advance warning, that warning should be given as far in advance as practical. Since leap seconds can only occur on month boundaries, starting to announce LI shortly after the start of a relevant month is appropriate.
The last time I was looking at the code, it was set to only do leap seconds in June and December. And then only on the last day.
Part of the problem with announcing it too early is due to bugs with other clocks. A hp clock steered to gps used to misfire if the GPS system announced the next leap second before Sept 30th, it would insert a leap second into the info it gave upstream on Sept 30th. I think the existing code was added out of an abundance of caution to ensure that buggy downstream ntpd do the right thing.
Don't know if there are any such buggy systems, but my conservative engineering sense suggests that any change like this be done in July of this year, just in case...
More information about the hackers