[ntp:questions] Re: ntp servers reporting leap second erroneously?
David L. Mills
mills at udel.edu
Sat Oct 15 16:29:47 UTC 2005
See the comments in the leap-seconds file via ftp from time.nist.gov.
Currently, steps are provisionally implemented in NIST and NTP only on
30 June or 31 December. Your argument is with not me or World Standards
Day; it is with NIST.
I have no idea how you arrived at a prediction when multiple steps in
one year would be required. With great relief it seems the IERS UT1
curve shows that the UTC offset from TAI continues to increase, although
slowly. My fear is that it might decrease, eventually causing a delete
second event, which is not possible in NIST radio timecode formats.
Steve Allen wrote:
> Marc Brett wrote:
>>On Sat, 15 Oct 2005 00:33:24 GMT, Greg Hennessy
>><greg.hennessy at tantalus.no-ip.org> wrote:
>>>How does NTP tell if the leap second is to added on Dec 31, Jun 30,
>>>Sep 30th or Mar 31st?
>>It can't. NTP simply _assumes_ leap second insertions on Dec 31 or June 30.
>>For leap seconds scheduled for the end of any other month the whole NTP leap
>>second model breaks down
> This is a bit ironic to point out on World Standards Day.
> The standard defining UTC has admitted leap seconds at the end of *any*
> month since its 1974 revision when it incorporated the advice from the
> 1973 General Assembly of the IAU.
>>Maybe we should petition the NAVSTAR people (and operators of all time signals)
>>to hold off inserting leap second announcements until the beginning of the month
>>in which they will occur?
> It seems to me that everyone else should also be petitioned to
> implement the UTC standard as written. We can expect that there
> are still some 50 years before more than two leap seconds per
> year will be needed, so that's plenty of time to retire or upgrade
> all existing systems. There's almost 300 years before more than
> 4 leap seconds per year will be needed. Any system with
> that much foresight would be hard to criticize.
More information about the questions