Re: [Ntp] Antw: Re: Finding leap-seconds.list

[Warner Losh <[e-mail]>]

On Mon, Nov 12, 2018 at 12:29 PM Hal Murray <[e-mail]> wrote:

>
> [e-mail] said:
> >> new TZ data should be made availale whenever a
> >> new leapsecond file is available (or at least significantly
> >> before the last one expires).
>
> > Of course, but how long is "significantly"?
>
> > In contrast, we reliably get about six months' notice for a leap second.
> We
> > batch that into the next tzdb release, whenever it happens to occur for
> other
> >  reasons. We've never had the problem of no timezone changes for six
> months
> > so  this has been good enough for us. (We would make a release for leap
> > seconds  reasons only, if need be.)
>
> I think things will be fine as long as you are willing to push out a
> leap-only
> release if nothing else happens for a month.  The point is that you don't
> get
> the whole 6 months.
>
> Here is my list of the steps that have to happen for sites that get it via
> their distro:
>   1: IERS announces leap or non-leap via bulletin C
>   2: NIST updates leap-seconds.txt
>   3 TZDB releases updated copy from NIST
>   4  distro releases update to TZDB
>   5  end system picks up new TZDB from distro
>   6  ntpd announces to downstream clients
>
> If we assume the first two steps take a month and allow a month each for
> steps
> 3, 4, and 5, that still leaves a month of slop if the announcements are to
> get
> out a month early.
>

The deadline for #6 is leap-second day, correct? ntpd only announces an
impending leap second in the last 24 hours before the leap second. Or is
that just a reference implementation detail. When there's no leap second
the deadline is a few days before since that's the expiration of the
previous file.

Also, to be clear, as far as ntpd is concerned, steps 3, 4, 5 are all
*optional* if there's another mechanism to pull in a new leap-second.txt
file from elsewhere. #5 implies an upgrade of at least some of the packages
on the system. While that's *A* way to do it, there are other equally valid
ways. We should allow for the extra time, of course, for this to happen.

I don't think we need to, however, allow for a worst case scenario where
IERS announces 8 weeks prior to the leap second. While that's technically
the current documented SLA (or was when i last checked), I believe they've
adopted first week in January deadline for when there's is a leap second
because it's now clear 3 months before that whether or not there will need
to be one. TOD forecasting has come a long way since 1972.

tl;dr: I think the current release cycle of the tzdb folks address the
needs here adequately.

Warner

P.S. Sorry if I'm being too nit-picky here, but traditionally there's been
a wide diversity of methods for obtaining leap-seconds.txt, and it would be
premature to standardize on the above list.