[tz] Unexpected last transition in Africa/Casablanca

Almaz Mingaleev mingaleev at google.com
Wed Mar 23 09:31:17 UTC 2022

"negative DST" is used in the main & varguard data format. On Android we use
rearguard format, where (among other differences) DST saving is always

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 at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20220323/8e689b15/attachment.htm>

More information about the tz mailing list