<div dir="ltr"><div>Thanks for fix!</div><div><br></div>Can't really tell about Java, haven't spoken with OpenJDK folks.<div><br></div><div>The last time I've asked ICU about negative DST offsets they had</div><div>no plans to support them. On the Android side we have a list of</div><div>things that can go wrong, but given ICU situation no work has been</div><div>done in that direction yet.</div><div><br></div><div>> Java currently can't even handle POSIX TZ strings much</div><div>Old APIs (java.util.TimeZone) definitely can't handle DST only time</div><div>zones, but I _think_ that new APIs* are in better shape and can</div><div>handle POSIX TZ strings.</div><div><br></div><div><br></div><div>* Well, Java 8 was released in 2014, maybe not that new</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 18 May 2022 at 18:41, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/18/22 02:32, Almaz Mingaleev wrote:<br>
<br>
> Unfortunately changing isdst flag only won't help here - in this case the<br>
> last<br>
> DST and STD transition offsets are equal, which breaks DST savings finding<br>
> logic - it would return 0, as in my first email, where last DST and STD<br>
> offsets<br>
> are 1 hour.<br>
> <br>
> On Wed, 30 Mar 2022 at 19:36, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>> wrote:...<br>
>> perhaps we should revert all these workarounds, and go back<br>
>> to what we were doing in this area before commit<br>
>> cec7d9e2e83f8a3faa2367e0d45383a1557889ed dated 2022-01-10 11:31:54 -08.<br>
<br>
OK, in that case let's revert as mentioned above. I installed the <br>
attached proposed patch into the development repository.<br>
<br>
It is a bit disconcerting to see comments like the following <br>
<<a href="https://android.googlesource.com/platform/external/icu/+/master/android_icu4j/libcore_bridge/src/java/com/android/i18n/timezone/ZoneInfoData.java#716" rel="noreferrer" target="_blank">https://android.googlesource.com/platform/external/icu/+/master/android_icu4j/libcore_bridge/src/java/com/android/i18n/timezone/ZoneInfoData.java#716</a>>:<br>
<br>
>             // This test means that for somewhere like Morocco, which tried DST in 2009 but has<br>
>             // no future plans (and thus no future schedule info) will report "true" from<br>
>             // useDaylightTime at the start of 2009 but "false" at the end. This seems appropriate<br>
<br>
which indicates that the code (or at least its commentary) doesn't match <br>
reality, as Morocco obviously is using DST now (whichever way you model <br>
it). It's not good that TZDB now has yet another rearguard hack to work <br>
around the code's mismatch with reality.<br>
<br>
What would it take to get this fixed properly in Android and ICU and <br>
Java, and to support negative DST and all that? I know this can't be <br>
fixed overnight, but what would it take for a fix in the long run? As I <br>
understand it, Java currently can't even handle POSIX TZ strings much <br>
less TZDB data, and surely this is undesirable even aside from TZDB.</blockquote></div>