Time-zone database issues
ramanand.patil at oracle.com
Fri Oct 26 07:52:19 UTC 2018
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 ]
> -----Original Message-----
> From: Naoto Sato
> Sent: Thursday, October 25, 2018 8:48 PM
> To: Stephen Colebourne <scolebourne at joda.org>; core-libs-dev <core-libs-
> dev at openjdk.java.net>
> Subject: Re: Time-zone database issues
> Thanks, Stephen.
> I filed an issue for your suggestion:
> 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
> On 10/22/18 3:25 PM, Stephen Colebourne wrote:
> > The IANA time-zone database  provides details of how time-zones
> > change over time. The latest release - 2018f - cannot be processed
> > successfully by the current JDK parser . 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 . 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  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
> >  https://www.iana.org/time-zones
> >  https://bugs.openjdk.java.net/browse/JDK-8212684
> > 
> > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time
> > /zone/ZoneOffsetTransitionRule.html
> >  https://www.threeten.org/threetenbp/
More information about the core-libs-dev