[ntp:hackers] Leap second list file
dennis.c.ferguson at gmail.com
Mon Jan 16 12:15:59 UTC 2012
On 16 Jan, 2012, at 17:28 , David J Taylor wrote:
>> 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.
>> Dave Hart
> Whilst not doubting the competence of our coders, a large part of me says "If it works, leave it". After all, changes mean documentation changes as well, and make existing copies of documentation false.
> Having said that, I can see why you might want more than one day's notice, so I would suggest making the notice period seven days, rather than one day, if that change can be accommodated.
> What would be the danger of firing the leap change seven times, though, were this done? Is your "after the first hour" to avoid the chance of accidentally making more than one change per month? On reflection, perhaps the month is the more natural unit in any case. Make it 24 hours so that any time zone doesn't get a potentially confusing indication, perhaps?
The reason that an earlier warning might be nice is that many systems have
both a file and some NTP stratum 1 servers (and if you are a stratum 1 server
you'll probably have a reference clock which gives you leap warnings; I think
the only time service I know of which doesn't now is GLONASS), all of which are
supposed to indicate the upcoming leap second. If the daemon could count on
getting the warnings earlier it could begin to complain of inconsistencies earlier,
like the time service indicating a leap second that isn't in the file or the file
having a leap second the time service isn't warning about, so you could maybe
fix the thing which is inconsistent before the leap second rather than finding
out about it afterward.
I vaguely remember that, when the NTP packet format was defined, the only
time service available at the time which provided a leap second warning was GOES and
I think it provided the warning only a day in advance. There may be a connection
between that and NTP providing its warning a day in advance.
More information about the hackers