[tz] Unexpected last transition in Africa/Casablanca

[Almaz Mingaleev]

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 at 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 at 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_icu4j/libcore_bridge/src/java/com/android/i18n/timezone/ZoneInfoData.java#716
> >:
>
> >             // 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220519/004bd139/attachment.html>