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

[Paul Eggert]

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.