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.