On Tue, 8 Jun 2021 at 17:23, Paul Eggert via tz <tz@iana.org> wrote:
On 6/8/21 1:56 AM, Stephen Colebourne via tz wrote:
It is possible to automatically derive the data for group 1 from the data for group 2. The other way around is not possible.
That's OK, as I'm not proposing the other way around. I'm merely proposing a flag to generate either group-1-style or group-2-style data from what we have now. This should be doable relatively easily. (And if I'm wrong, we can revisit this technical issue of course.)
Are you proposing a makefile option to recreate the original source files using the data in backzone? That seems much harder work than doing it the other way around and prone to error. (Remember that downstream projects need the correct source files, not any other output file) One key advantage of the `idmerge` file is that it makes the merge process obvious. ie. that TZDB favours Berlin over Stockholm/Oslo. I'm proposing that the historic data is present in its original location (africa to southamerica). And I propose that the flag and `idmerge` provide the necessary tools to reduce the file size for those that need it. The importance of the full dataset being the default can be seen here for example: https://www.oracle.com/java/technologies/javase/tzupdater-readme.html As can be seen, the docs expect users to download the latest tarball. It isn't reasonable for TZDB to demand all downstream users change their URL. Another variant of the same tool: https://docs.azul.com/core/timezone-updater Here is another example, where a downstream system has had to adapt to retain compatibility: http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/801874e394a7/make/gendata/Ge... https://github.com/openjdk/jdk/blob/master/make/data/tzdata/jdk11_backward I know CLDR has previously expressed significant concern about the compatibility issue too. Stephen