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