[tz] [tz-announce] 2018f release of tz code and data available
eggert at cs.ucla.edu
Sat Oct 20 23:43:45 UTC 2018
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:
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