Hi, This sounds great! Thanks for taking the time to investigate. Can you clarify what is generated? As a reminder, the tooling chains that global-tz supports need the *source* files (africa, europe, northamerica...) to contain the data for Zone per ISO-3166. This is because: - they contain their own parsers of the source data [1] [2] [3] - the parsers typically operate and expose data in rearguard mode (no negative DST) [4] - they consume and expose the last Rule line for each zone [5] If the source data is available as a result of the make command then there should be no long term need for global-tz. If the source data is not available as a result of the make command, then sadly global-tz would still be needed unless the patch can be enhanced. thanks Stephen [1] https://github.com/ThreeTen/threetenbp/blob/master/src/main/java/org/threete... [2] https://cldr.unicode.org/development/updating-codes/update-time-zone-data-fo... [3] https://github.com/openjdk/jdk/blob/master/make/jdk/src/classes/build/tools/... [4] https://github.com/JodaOrg/global-tz/releases/tag/2022agtz [5] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/time/zone/... On Wed, 27 Jul 2022 at 02:19, Paul Eggert via tz <tz@iana.org> wrote:
I wangled a bit of free time and wrote the attached proposed patch, which adds an option that causes 'make install' to generate time zone data (TZif files) that are byte-for-byte identical to what Stephen Colebourne's global-tz currently generates. This is done via a few lines of awk script. The idea is to give an option to distros that prefer a separate Zone per ISO 3166 country, just as we already have build-time options for rearguard/vanguard form, TZif truncation, leap seconds, etc.
I haven't installed this in the development database. Comments welcome as usual.