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.