The java.time.* code exposes the local time that the transition occurs. This can be represented within the bounds 00:00 to 24:00. There is no way to represent 25:00 or negatives.
https://docs.oracle.com/javase/8/docs/api/java/time/zone/ZoneOffsetTransitionRule.html

As such, the tzdb parser would have to convert 25:00 and try to reinterpret it as the next day within the valid bounds, which is far from ideal. It would be much better for the upstream source to represent the data in a more standard and backwards compatible way. 

(The existing API will be supported unaltered for many years, potentially decades, so changing the API is not a viable solution.) 

Stephen 


On Thu, 18 Oct 2018, 19:15 Paul Eggert, <eggert@cs.ucla.edu> wrote:
On 10/18/18 8:14 AM, Christos Zoulas wrote:
> My folks are reporting that java does not like it:
>
> ERROR: Failed: java.lang.Exception: Failed while parsing file
> '/tmp/tz.tmp_2/asia' on line 1655 'Rule       Japan   1948    1951    -       SepSat>=8 25:00 0       S'
> ERROR: java.lang.Exception: Failed while parsing file
> '/tmp/tz.tmp_2/asia' on line 1655 'Rule       Japan   1948    1951    -       Sep     Sat>=8 25:00    0       S'
>
Thanks for the heads-up; please try the attached patch.

Is there some way your folks can try the development version on GitHub
every now and then? That "25:00" has been in the development version
since last month and was explicitly called out when the patch was
circulated on the mailing list
<https://mm.icann.org/pipermail/tz/2018-September/026891.html>. It'd
have been nice to catch the glitch before 2018f came out.