[tz] tzdist and tz at iana

Lester Caine lester at lsces.co.uk
Wed Sep 7 22:46:43 UTC 2016

On 07/09/16 21:16, Paul Eggert wrote:
> On 09/07/2016 11:35 AM, Lester Caine wrote:
>> tz was always viewed as the primary source for tzdist, until there IS a
>> primary source we can't start to create mirror sites.
> But there is a primary source for tz: the latest release as described at
> https://www.iana.org/time-zones. This consists of the two gzipped
> tarballs that we've been talking about, currently the 2016f release.
> These tarballs can easily be mirrored elsewhere.

There needs to be a seed tzdist service somewhere so that the
distribution mechanism designed into the protocol can be used. It has no
provision to be seeded from tarballs ... that would have to be done
manually initially, and then updates are via diffs to the current
version. Some servers may well ignore tz updates and apply each change
as they happen, but personally I think that is only going to make
maintaiing historic data more difficult.

> A complete tzdist public server would need to do more than just
> mirroring tz releases. That would be a bigger project, one outside the
> scope of tz proper.
>> We need a master that can provide
>> the complete history of changes to tz data properly identified, or at
>> least one starting from a current live version.

> The iana.org website publishes all the tz releases that we've been able
> to get our hands on. Some older releases have been lost, alas, but I
> think we have every release published since 1999. For details, look for
> the string "is missing!" in the NEWS file.

While the provision of an historic tz version via tzdist is not a
particularly difficult task. As Paul says, it's a one time step. The
more important thing is to have a current version of tz available
against which the update process can be implemented so creating the
various 'diff' options. Essentially a fully functional tzdist service
would allow you to check a legacy calendar complied with version x-? and
find out if information on that clendar may be affected b a later change
... any later change. And if your system is working internally with a
leapsecond clock, that would also include indication that times recorded
for next year will need a one scond update once the leapsecond change is
also posted.

Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

More information about the tz mailing list