[tz] Please remove tzdata2018f
Brian.Inglis at Shaw.ca
Fri Feb 22 17:56:32 UTC 2019
So tzupdater still requires to make or use the rearguard tarball as before.
On 2019-02-22 08:46, Stephen Colebourne wrote:
> There are three different parsers I've been involved with:
> - Joda-Time
> - ThreeTen-Backport
> - JSR-310 as integrated into Java 8 and later
> At present, Joda-Time can handle the latest TZDB format, dynamically
> reverting the breaking changes made to the file format. The approach
> taken is imperfect and will no doubt break again at some point in the
> ThreeTen-Backport has a fix for 25:00 mentioned above:
> I believe the Java 8 parser requires the rearguard format, but it is
> not controlled by me anymore.
> On Fri, 22 Feb 2019 at 01:15, Marcos Passos <marcospassos.com at gmail.com> wrote:
>> Stephen can confirm it, but I built all versions since 2018 using JSR-310 a few months and the result was correct.
>> On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip at trouble.is> wrote:
>>> On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:
>>>> While doing tzdata upgrade to version 2018f
>>> Note that you should really be upgrading to 2018i, which is the latest
>>>> java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on
>>>> line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0
>>> Java is known to be broken with respect to the last ten years or so of
>>> changes to the tzdb data format. You'll need to generate "rearguard"
>>> format data to feed to the Java updater.
>>> Paul also helpfully provides rearguard tarballs on his webpage
>>> You can easily generate those yourself by running make
>>> rearguard_tarballs on the distribution from iana.org.
>>>> To avoid any reoccurrence of same, would it be possible to prevent the
>>>> tzdata version 2018f from downloading on iana site?
>>> It seems silly to pull one release from an archive going back to 1993
>>> because one third-party implementation (even if it's a popular one)
>>> cannot cope with the data format.
>>> Philip Paeps
>>> Senior Reality Engineer
>>> Ministry of Information
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
More information about the tz