Although most Java users like me and millions other really appreciate your work very much, I fear you don't fully understand how Java world works/ticks. The big majority of Java users is not willing to run any shell scripts or macros just because it would not be compatible with the major goal to create platform-independent Java software. So the only real primary interface from the perspective of a Java user consists of the source code files like "Africa", "Europe" etc. I myself can surely not use your macro "Make" because that would require me and other users of public Java APIs to download extra non-Java-software components even on unknown future platform-specific environments. It is only interesting for those Java users who just develop private-only tools for a known specific platform but this is clearly a minority. And I still think that extra source code files with documented reliable formats would far more serve the specific needs of Java users without the need to change the zic input, so no problem either for the Unix-world or for Java commune. Macros and shell scripts might be very fine in Unix world but are a no-go for most Java users. I hope that you take this into your considerations. Meno Am 10.02.2018 um 00:11 schrieb Paul Eggert:
On 02/06/2018 07:40 AM, Stephen Colebourne wrote:
Users are encouraged to update the time-zone data themselves: http://www.joda.org/joda-time/tz_update.html http://www.threeten.org/threetenbp/update-tzdb.html
They should continue to be able to do that. joda.org, threeten.org, etc. can continue to distribute tarballs in rearguard format or whatever other format they like, and users can use those tarballs. Something like this should be done regardless of whether there is any format change, as iana.org doesn't have the resources to support every device on the planet directly.
Since zic/make is not run, how is a downstream consumer going to use them A process at joda.org, threeten.org, etc. can run 'make' to generate a tarball that contains files in rearguard format, and then joda.org, threeten.org etc. can redistribute that tarball. Assuming the current development version, the process could run something like the following, say.
make rearguard.zi mkdir tzrear.dir ln rearguard.zi tzrear.dir/africa for file in antarctica asia australasia europe northamerica southamerica etcetera systemv factory backward ; do \ touch tzrear.dir/$file || exit; \ done (cd tzrear.dir && \ tar -cf - africa antarctica asia australasia europe northamerica southamerica etcetera systemv factory backward ) | \ gzip >tzrear2018c.tar.gz
No doubt this will require minor tweaking to pacify whatever quirks OpenJDK has, but I hope you get the idea.
The point is that if OpenJDK wants a particular tweak to the format, then it should be in charge of its own destiny, and not be at the mercy of upstream changes. This is what other distributors do, and it's a good time for OpenJDK to start following their lead.