"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,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?