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@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,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.