[tz] [tz-announce] 2018f release of tz code and data available

[Per Kristian Fjellby]

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.
>