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

[Paul Eggert <[e-mail]>]

Ulrich Windl wrote:
> 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"?

Time zone announcements are sometimes made by governments with very little 
notice; for example, we had only 39 hours' notice for last month's change to 
Morocco's rules. (These governments are being unrealistic of course, but we're 
trying to train them by arranging for their cell phones' clocks to be wrong if 
they don't give us more notice. :-) Although the tzdb process turns around such 
notices reasonably quickly we prefer being given longer notice; in that case we 
wait for a while because there is a cost to releasing a new tzdb version (a cost 
to us and more importantly to downstream users) and we'd like to lessen that 
cost by batching multiple changes into a single release. Plus, sometimes 
governments revert their changes before they take effect, or we're given false 
alarms for other reasons, and in such cases we can avoid releasing the wrong data.

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.)

Some users who need just the leap-seconds.list file have written to the tz 
mailing list saying that they don't want to wait for the next tzdb release; they 
want the latest leap-seconds.list file now, even if its set of leap seconds is 
identical to the previous set (because they also want the file's expiration 
date). These users are not well-served by the current tzdb release policy which 
is oriented for tzdb's needs, not for leap-seconds.list needs. Are these users 
primarily motivated by NTP? If so, what's the use case here and why is the 
expiration date so important? (That date is ignored by tzcode.) I can't imagine 
maintaining an NTP server without having a mechanism to update its leap second 
data that could work with (say) a month's notice which would mean that the 
current tzdata policy should be good enough, but I'm not that plugged into how 
NTP servers are actually deployed.

If the need is great enough, it'd be helpful to set up a distribution mechanism 
for just leap-seconds.list that fulfills NTP's needs better and I could talk to 
the IANA folks about doing that. Of course iana.org wouldn't want to be 
overloaded by billions of devices constantly polling it....