Hi Naoto, Thank you for filing the bug. As far as tzdata2018f release is concerned I am going ahead with the integration, with the help of the patch provided here- https://mm.icann.org/pipermail/tz/2018-October/027032.html Which avoids 25:00 in rearguard format. [ https://bugs.openjdk.java.net/browse/JDK-8213016 ]
Regards, Ramanand. > -----Original Message----- > From: Naoto Sato > Sent: Thursday, October 25, 2018 8:48 PM > To: Stephen Colebourne <scolebou...@joda.org>; core-libs-dev <core-libs- > d...@openjdk.java.net> > Subject: Re: Time-zone database issues > > Thanks, Stephen. > > I filed an issue for your suggestion: > > https://bugs.openjdk.java.net/browse/JDK-8212970 > > I will need to look into the issue, but so far as I understand, will it be > fine to > modify the offending transition date to the next day for 2018f's immediate > issue? > > Naoto > > On 10/22/18 3:25 PM, Stephen Colebourne wrote: > > The IANA time-zone database [1] provides details of how time-zones > > change over time. The latest release - 2018f - cannot be processed > > successfully by the current JDK parser [2]. A workaround exists > > however unlike previous cases of tzdb incompatibility, this time it > > makes sense for the JDK parser and API to be changed. > > > > Problem > > ----------- > > The JDK parser and API make the assumption that a time-zone change can > > occur at any LocalTime or midnight-end-of-day, ie. from 00:00 to > > 24:00. Unfortunately, the tzdb source files allow (and now include) > > rules outside those valid values, in this case a value of 25:00. > > Specifically, the rule that causes problems says that clocks change at > > 25:00 on the first Saturday on or after the 8th of September. > > > > In the current problematic case, the rule can be rewritten to say that > > clocks change at 01:00 on the first Sunday on or after the 9th of > > September. However, there are cases where it is difficult to > > impossible to rewrite the rule (such as 25:00 on the last Saturday in > > a month, difficult because it goes into the next month). > > > > Proposed solution > > ------------------------ > > > > Fixing the parser to handle values like 25:00 would be relatively > > easy. However, these rules are also exposed in the public API of > > java.time.zone.ZoneOffsetTransitionRule [3]. Currently this class has > > methods `getLocalTime()` and `isMidnightEndOfDay()`. These would need > > to be deprecated and replaced by a new method `getLocalTimeDuration()` > > (or some other name) that returns an instance of `Duration`. > > > > A user of ThreeTen-Backport [4] has provided a branch to do this, so I > > know the change to be possible. However, since I have looked at the > > code I cannot implement the change in OpenJDK (compromised IP). It > > needs a cleanroom implementation by someone else. > > > > Is there agreement on the need for change? Is anyone (Oracle or > > otherwise) willing to volunteer do the work? > > > > thanks > > Stephen > > > > > > [1] https://www.iana.org/time-zones > > [2] https://bugs.openjdk.java.net/browse/JDK-8212684 > > [3] > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time > > /zone/ZoneOffsetTransitionRule.html > > [4] https://www.threeten.org/threetenbp/ > >
