[tz] [tz-announce] 2018f release of tz code and data available

Stephen Colebourne jodastephen at gmail.com
Mon Oct 22 21:59:58 UTC 2018


I'm willing to argue for a change to the Java API as there are
definitely rules that can't be expressed in any other way except via
out of bounds times.

However, there is no particular reason for this particular rule to be
expressed as out of bounds 25:00. In addition to Java itself, there
are a number of other Java libraries impacted by this. As I've pointed
out before, the rearguard approach does not really help because it is
not a distributed set of source files - it requires pre-processing.

Since there is no difference to the output timestamps, and no
particular reason to express the rule as 25:00, can we agree to revert
the main source file to use 01:00 until release 2020a to give time for
the change to percolate through the libraries?

thanks
Stephen


On Sun, 21 Oct 2018 at 00:43, Paul Eggert <eggert at cs.ucla.edu> wrote:
>
> Stephen Colebourne wrote:
> > It would be much better for the upstream source to represent the data in a
> > more standard and backwards compatible way.
>
> The original Japanese regulation does seem to say that the transition occurs
> Saturday at 25:00 (as this is how such times are often expressed in Japan), and
> it's better to represent data as close to the original as the format allows.
> This is not a recent change to the format, which was relaxed to allow 25:00 (and
> other out-of-range times) in 2007, as first proposed here:
>
> https://mm.icann.org/pipermail/tz/2007-May/014341.html
>
> with no disagreement at the time.
>
> > (The existing API will be supported unaltered for many years, potentially
> > decades, so changing the API is not a viable solution.)
>
> This sort of compatibility issue is what rearguard format is for, and the patch
> proposed in <https://mm.icann.org/pipermail/tz/2018-October/027032.html> should
> suffice for the existing Java API, which as I understand it needs to use
> rearguard format anyway. Success for this approach with OpenJDK has been
> reported in <https://bugs.openjdk.java.net/browse/JDK-8212684>.
>
> When someone has the time, though, the Java API should get fixed, as insisting
> on times in the range 00:00-24:00 prohibits useful and practical rules. It's not
> just Japan; it's also rules like "22:00 on the day before the last Sunday in
> March" that are quite plausible in real-world practice.


More information about the tz mailing list