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.