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 it is. 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 quite short. 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. -zefram