[tz] Unexpected last transition in Africa/Casablanca

[Almaz Mingaleev]

Hi Paul,
Sorry for the delay.
Unfortunately changing isdst flag only won't help here - in this case the
last
DST and STD transition offsets are equal, which breaks DST savings finding
logic - it would return 0, as in my first email, where last DST and STD
offsets
are 1 hour.

On Wed, 30 Mar 2022 at 19:36, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 3/29/22 09:33, Almaz Mingaleev wrote:
> > Removing the last transition would help.
>
> OK. However, doing that would cause the rearguard and main timestamps to
> disagree in UTC offset for a month or so. It'd be less intrusive to add
> a transition after the last transition, which I hope would also work
> around the problem (as it'd exhibit a similar pattern) but would cause
> the rearguard and main timestamps to disagree only with respect to the
> isdst flag for a day, which is less of a difference.
>
> I installed the attached proposed patch to do that. Does it work for
> you? If not, perhaps we should revert all these workarounds, and go back
> to what we were doing in this area before commit
> cec7d9e2e83f8a3faa2367e0d45383a1557889ed dated 2022-01-10 11:31:54 -08.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220518/4a3f48d9/attachment.html>