Just my two cents.. I needed to patch up our JDKs since we need the Volgograd-patch and can't wait for an official release. That meant me hitting the same problem as described in https://bugs.openjdk.java.net/browse/JDK-8212684 and having to build the rearguard from the tz-source myself. Would it be possible to host these *guard-builds on the iana.org/time-zones page as well, giving downstream users that will have to rely on these releases for some time a place to find them without building them from source? Apart from saving us a build it also gives people who are not following the tz-code closely a notice that something has changed and that they need to watch out for this. Thanks. //Per Kristian On 25. okt. 2018 10:40, Paul Eggert wrote:
On 10/24/18 5:16 AM, Stephen Colebourne wrote:
The issue is that virtually no-one knows about those additional distributions.
That issue will always be with us; it won't be any different in 2019 or 2020 than it is now. And we had the same issue in 2011 when we made the transition from elsie.nci.nih.gov and changed distribution URLs. Java users did OK back then, and I don't see why we need to do this transition differently.
The underlying problem here is that Java-based .zi parsers and operational procedures are too tightly coupled to tzdb format details that the Java parsers support only imperfectly or with a long lag time, and this problem will continue as long as tzdb evolves (which it will). A good way to address the problem is for Java to do what every other significant downstream distribution does, which is to redistribute the data the way Java wants it, thus decoupling the tzdb distribution from the Java distribution. There will be glitches when this decoupling is accomplished, regardless of whether it's done in the next tzdb release or a dozen tzdb releases from now, and we might as well get started now.