<div dir="ltr">"negative DST" is used in the main & varguard data format. On Android we use<div>rearguard format, where (among other differences) DST saving is always positive.</div><div><br></div><div>Issue with the generated TZif file is that last transitions are marked as standard, even</div><div>though the last one technically is DST. See Paul's reply [1] why it is so.</div><div><br></div><div>[1] <a href="https://mm.icann.org/pipermail/tz/2022-March/031334.html">https://mm.icann.org/pipermail/tz/2022-March/031334.html</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 22 Mar 2022 at 21:13, Kerry Shetline via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">This image might make the issue clearer: <a href="https://i.imgur.com/6PFLDeWh.png" target="_blank">https://i.imgur.com/6PFLDeWh.png</a></div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br><blockquote type="cite">Here are the last transitions in Africa/Casablanca output (rearguard</blockquote></div><blockquote type="cite"><div dir="ltr"><span>format):</span><br><span></span><br><span>transition,type,[UTC time],[Type offset],[Type isDST]</span><br><span><a href="tel:(367)%20261-2000" value="+13672612000" target="_blank">3672612000</a>,1,2086-05-19T02:00:00Z,PT1H,DST</span><br><span>3699828000,2,2087-03-30T02:00:00Z,PT0S,STD</span><br><span>3703456800,3,2087-05-11T02:00:00Z,PT1H,STD</span><br><span></span><br><span>So change is from standard to standard, even though offset changes from 0h</span><br><span>to 1h. Is that expected behaviour?</span><br></div></blockquote></div></blockquote></div>