<div><div><div dir="auto">Brian,</div></div><div dir="auto"><br></div><div dir="auto">I used these files:</div><div dir="auto"><div><a href="https://data.iana.org/time-zones/releases/" target="_blank">https://data.iana.org/time-zones/releases/</a></div><br></div><div dir="auto">Regards,</div><div dir="auto">Marcos</div></div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 22, 2019 at 01:01 Brian Inglis <<a href="mailto:Brian.Inglis@systematicsw.ab.ca" target="_blank">Brian.Inglis@systematicsw.ab.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2019-02-21 18:19, Philip Paeps wrote:<br>
> On 2019-02-22 10:14:52 (+0900), Marcos Passos wrote:<br>
>> On Thu, Feb 21, 2019 at 21:55 Philip Paeps <<a href="mailto:philip@trouble.is" target="_blank">philip@trouble.is</a>> wrote:<br>
>>> On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote:<br>
>>>> While doing tzdata upgrade to version 2018f<br>
<br>
>>> Note that you should really be upgrading to 2018i, which is the latest version.<br>
<br>
>>>> java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on<br>
>>>> line 1842 'Rule      Japan 1948  1951  -     Sep   Sat>=8      25:00 0     S'<br>
<br>
>>> Java is known to be broken with respect to the last ten years or so of<br>
>>> changes to the tzdb data format.  You'll need to generate "rearguard" format<br>
>>> data to feed to the Java updater.<br>
<br>
>> Stephen can confirm it,  but I built all versions since 2018 using JSR-310 a<br>
>> few months and the result was correct.<br>
<br>
> Last I read on the tz mailing list, the Java tzdb parser doesn't like negative<br>
> SAVE rules or more than 24 hours in a day.  Happy to hear that was fixed at last.<br>
> Thank you for pointing that out.<br>
<br>
Marcos didn't say whether it was vanguard, standard, or rearguard format data<br>
that was used for 2018. As JSR 310 appears to be unchanged since 2014, until<br>
Marcos or Stephen explicitly states otherwise, it would be safer to continue to<br>
assume that rearguard format data is required.<br>
<br>
-- <br>
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada<br>
<br>
This email may be disturbing to some readers as it contains<br>
too much technical detail. Reader discretion is advised.<br>
</blockquote></div></div>
</div>