[tz] Data loss on FTP Server
zefram at fysh.org
Sun Oct 29 21:44:47 UTC 2017
Kim Davies wrote:
>Is retrieving old versions of the tzdb a common use case?
I frequently look at old versions, to find out what changed and when, to
find the origins of ideas, and so on. I'm not a typical user, of course,
and my uses for the history can now to some extent be satisfied by git.
But the sequence of tzdb releases is a well-defined historical record,
and ought to be accessible.
>I'm happy to explore providing additional metadata in a structured way
>if that is useful.
With respect to the current database, I'd like to be able
* to determine whether I already have the current version; and
* to download the current database while being aware of what version
Merely downloading the current version can be accomplished by the use of
"-latest" links. Those links used to be insufficient to determine what
version the latest is, because until recently the distribution didn't
contain anything saying (in a reasonably machine-readable manner) what
version it is. However, the "version" file in recent distributions is
a solution to this, if it can be relied upon.
To determine whether I have the current version, I have been accustomed
to looking at the list of files available to determine what the current
version is. Currently this means looking at the directory containing
all the releases, which is quite a lot of names, so actually not an ideal
process. Back in the elsie days, the main directory normally contained
only the current version (and had it under versioned filenames, unlike
the present "-latest" links), so the list of filenames to look at was
It would be nicer to have some kind of retrievable thing that just
directly tells me what the latest version is. With the "version" file
in the distribution, I could theoretically just download a "-latest"
tarball and read its "version" file, but that's a disproportionately
large amount of material to download just to get a version number.
(My automation checks for the latest version about a thousand times for
each one occasion when there's actually a new version to download.)
The ideal would be to have an HTTP(S) URL that gives just the latest
version number, as a plain text file in the same format as the "version"
file in the distribution.
There may be an additional wrinkle due to code and data portions of
the distribution having separate version numbers. Historically, and as
recently as 2012, a tzdata or tzcode release would be made without the
other half, the new version of the database being composed of tzdata
and tzcode releases that have different version numbers. Is that still
a possibility? The "version" file and the tzdb-*.tar.lz release files
give some impression that the two halves are now more tightly tied, and
that neither can be released without a matching release of the other.
If tzcode and tzdata can still have non-matching version numbers, then
rather than acquiring a single "latest version number" I need separate
latest version numbers for tzcode and tzdata.
With respect to historical versions of the database, I'd like to be able
* to determine, for a hypothetical historical version number, whether
there is in fact a release with that version number;
* to determine, for a genuine historical version number, the separate
version numbers of its constituent tzcode and tzdata portions;
* to download the tzcode and tzdata tarballs for a specified version
number, with signatures where applicable.
I can cope with there being a bounded number of historical exceptions
to whatever mechanisms we establish, though the tarballs ought to be
available in some form right back to the beginning. The important
thing is that there should be a reliable mechanism that applies to all
new versions as they get added to the historical record. If tzcode
and tzdata are henceforth to be released in lockstep, then the whole
question of separate version numbers falls under the "bounded number of
historical exceptions" rubric.
More information about the tz