"negative DST" is used in the main & varguard data format. On Android we use rearguard format, where (among other differences) DST saving is always positive. Issue with the generated TZif file is that last transitions are marked as standard, even though the last one technically is DST. See Paul's reply [1] why it is so. [1] https://mm.icann.org/pipermail/tz/2022-March/031334.html On Tue, 22 Mar 2022 at 21:13, Kerry Shetline via tz <tz@iana.org> wrote:

This image might make the issue clearer: https://i.imgur.com/6PFLDeWh.png

What happened is that what used to be called DST is now considered the standard time for this timezone, and what used to be standard time is now *negative* DST.

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?