[tz] Unexpected last transition in Africa/Casablanca
mingaleev at google.com
Mon Mar 28 16:03:16 UTC 2022
I see, thanks.
Unfortunately such standard-to-standard time transitions break
DST offset finding logic on Android (code is here ).
For now I've reverted  (ironically the problem was reported by me).
Is there a less intrusive way to keep the old behaviour?
On Tue, 22 Mar 2022 at 15:15, Paul Eggert <eggert at 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 <(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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz