[tz] [tz-announce] 2018f release of tz code and data available
Per Kristian Fjellby
p.fjellby at sportradar.com
Thu Oct 25 08:59:20 UTC 2018
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.
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
> 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.
More information about the tz