<div dir="ltr">Hi Paul,<div>Sorry for the delay.</div><div>Unfortunately changing isdst flag only won't help here - in this case the last</div><div>DST and STD transition offsets are equal, which breaks DST savings finding</div><div>logic - it would return 0, as in my first email, where last DST and STD offsets</div><div>are 1 hour. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 30 Mar 2022 at 19:36, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/29/22 09:33, Almaz Mingaleev wrote:<br>
> Removing the last transition would help.<br>
<br>
OK. However, doing that would cause the rearguard and main timestamps to <br>
disagree in UTC offset for a month or so. It'd be less intrusive to add <br>
a transition after the last transition, which I hope would also work <br>
around the problem (as it'd exhibit a similar pattern) but would cause <br>
the rearguard and main timestamps to disagree only with respect to the <br>
isdst flag for a day, which is less of a difference.<br>
<br>
I installed the attached proposed patch to do that. Does it work for <br>
you? If not, perhaps we should revert all these workarounds, and go back <br>
to what we were doing in this area before commit <br>
cec7d9e2e83f8a3faa2367e0d45383a1557889ed dated 2022-01-10 11:31:54 -08.</blockquote></div>