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