<div dir="auto"><div>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.<br><br><div class="gmail_quote"><div dir="ltr"> 2018-10-23 06:00, Stephen Colebourne <<a href="mailto:jodastephen@gmail.com">jodastephen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm willing to argue for a change to the Java API as there are<br>
definitely rules that can't be expressed in any other way except via<br>
out of bounds times.<br>
<br>
However, there is no particular reason for this particular rule to be<br>
expressed as out of bounds 25:00. In addition to Java itself, there<br>
are a number of other Java libraries impacted by this. As I've pointed<br>
out before, the rearguard approach does not really help because it is<br>
not a distributed set of source files - it requires pre-processing.<br>
<br>
Since there is no difference to the output timestamps, and no<br>
particular reason to express the rule as 25:00, can we agree to revert<br>
the main source file to use 01:00 until release 2020a to give time for<br>
the change to percolate through the libraries?<br>
<br>
thanks<br>
Stephen<br>
<br>
<br>
On Sun, 21 Oct 2018 at 00:43, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank" rel="noreferrer">eggert@cs.ucla.edu</a>> wrote:<br>
><br>
> Stephen Colebourne wrote:<br>
> > It would be much better for the upstream source to represent the data in a<br>
> > more standard and backwards compatible way.<br>
><br>
> The original Japanese regulation does seem to say that the transition occurs<br>
> Saturday at 25:00 (as this is how such times are often expressed in Japan), and<br>
> it's better to represent data as close to the original as the format allows.<br>
> This is not a recent change to the format, which was relaxed to allow 25:00 (and<br>
> other out-of-range times) in 2007, as first proposed here:<br>
><br>
> <a href="https://mm.icann.org/pipermail/tz/2007-May/014341.html" rel="noreferrer noreferrer" target="_blank">https://mm.icann.org/pipermail/tz/2007-May/014341.html</a><br>
><br>
> with no disagreement at the time.<br>
><br>
> > (The existing API will be supported unaltered for many years, potentially<br>
> > decades, so changing the API is not a viable solution.)<br>
><br>
> This sort of compatibility issue is what rearguard format is for, and the patch<br>
> proposed in <<a href="https://mm.icann.org/pipermail/tz/2018-October/027032.html" rel="noreferrer noreferrer" target="_blank">https://mm.icann.org/pipermail/tz/2018-October/027032.html</a>> should<br>
> suffice for the existing Java API, which as I understand it needs to use<br>
> rearguard format anyway. Success for this approach with OpenJDK has been<br>
> reported in <<a href="https://bugs.openjdk.java.net/browse/JDK-8212684" rel="noreferrer noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8212684</a>>.<br>
><br>
> When someone has the time, though, the Java API should get fixed, as insisting<br>
> on times in the range 00:00-24:00 prohibits useful and practical rules. It's not<br>
> just Japan; it's also rules like "22:00 on the day before the last Sunday in<br>
> March" that are quite plausible in real-world practice.<br>
</blockquote></div></div></div>