[tz] Unexpected last transition in Africa/Casablanca

[Almaz Mingaleev]

I see, thanks.

Unfortunately such standard-to-standard time transitions break
DST offset finding logic on Android (code is here [1]).
For now I've reverted [2] (ironically the problem was reported by me).

Is there a less intrusive way to keep the old behaviour?

[1]
https://android.googlesource.com/platform/external/icu/+/master/android_icu4j/libcore_bridge/src/java/com/android/i18n/timezone/ZoneInfoData.java#686
[2]
https://github.com/eggert/tz/commit/cec7d9e2e83f8a3faa2367e0d45383a1557889ed

On Tue, 22 Mar 2022 at 15:15, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 3/22/22 05:40, Almaz Mingaleev wrote:
> > Here are the last transitions in Africa/Casablanca output (rearguard
> > format):
> >
> > transition,type,[UTC time],[Type offset],[Type isDST]
> > 3672612000 <(367)%20261-2000>,1,2086-05-19T02:00:00Z,PT1H,DST
> > 3699828000,2,2087-03-30T02:00:00Z,PT0S,STD
> > 3703456800,3,2087-05-11T02:00:00Z,PT1H,STD
> >
> > So change is from standard to standard, even though offset changes from
> 0h
> > to 1h. Is that expected behaviour?
>
> Yes, as tzdb frowns on permanent daylight saving time for reasons
> discussed recently.
>
> This issue occurs due to the rearguard format's contortion of post-2018
> Morocco data to pretend that standard time is daylight saving and vice
> versa. Even with that contortion, we don't want the normal post-2087
> prediction (standard time only) to be contorted into a rearguard
> post-2087 prediction of daylight saving only.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220328/b593743c/attachment.html>