The difference between 25:00 abd 01:00 is that, assuming the DST transition take place at September 6 of certain year, then the last hour with DST active would be considered as part of September 6 if 01:00 approach is used, while it should be September 5 going to 25:00. 2018-10-23 06:00, Stephen Colebourne <jodastephen@gmail.com> wrote:
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@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.