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@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.