<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 6, 2017 at 1:25 PM, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 01/05/2017 10:05 PM, Bradley White wrote:<br>
> Regarding the localtime.c change, perhaps something better than<br>
> ignoring a transition that was "almost surely generated" because<br>
> of WORK_AROUND_QTBUG_53071, is to just ignore any trailing, no-op<br>
> transitions. That is, ...<br>
><br>
> + /* Ignore any trailing, no-op transitions generated<br>
> + * by zic as they don't help here and can run afoul<br>
> + * of bugs in zic 2016j or earlier. */<br>
> + while (1 < sp->timecnt &&<br>
> + sp->types[sp->timecnt - 1] ==<br>
> + sp->types[sp->timecnt - 2])<br>
> + sp->timecnt--;<br>
><br>
</span>I tried something like that but it that worked only on 32-bit clients<br>
because the transitions were still in the 64-bit data and were not at<br>
the end. My memory could be wrong (I didn't save all my work). Plus,<br>
perhaps it could be fixed up somehow. I agree that if someone could get<br>
something like the above to work in both 32- and 64-bit clients, with<br>
both the unfixed and the fixed zic, it'd be a better fix.<br></blockquote><div><br></div><div>Here is what I see for trailing 32-bit and 64-bit data in Pacific/Tongatapu using both the unfixed and fixed zic.</div><div><br></div><div><div><font face="monospace, monospace" size="1"> 32-bit data 64-bit data</font></div><div><font face="monospace, monospace" size="1">Unfixed zic:</font></div><div><font face="monospace, monospace" size="1"> 2115810000 [type=2] gmtoff=46800 is_dst=F abbr="+13" 2115810000 [type=2] gmtoff=46800 is_dst=F abbr="+13"</font></div><div><font face="monospace, monospace" size="1"> 2140606800 [type=5] gmtoff=50400 is_dst=T abbr="+14" 2140606800 [type=5] gmtoff=50400 is_dst=T abbr="+14"</font></div><div><font face="monospace, monospace" size="1"> 2147483647 [type=5] gmtoff=50400 is_dst=T abbr="+14" 2147483647 [type=5] gmtoff=50400 is_dst=T abbr="+14"</font></div><div><font face="monospace, monospace" size="1">Fixed zic:</font></div><div><font face="monospace, monospace" size="1"> 2115810000 [type=2] gmtoff=46800 is_dst=F abbr="+13" 2115810000 [type=2] gmtoff=46800 is_dst=F abbr="+13"</font></div><div><font face="monospace, monospace" size="1"> 2140606800 [type=5] gmtoff=50400 is_dst=T abbr="+14" 2140606800 [type=5] gmtoff=50400 is_dst=T abbr="+14"</font></div><div><font face="monospace, monospace" size="1"> 2147259600 [type=2] gmtoff=46800 is_dst=F abbr="+13" 2147259600 [type=2] gmtoff=46800 is_dst=F abbr="+13"</font></div><div><font face="monospace, monospace" size="1"> 2147483647 [type=2] gmtoff=46800 is_dst=F abbr="+13" 2147483647 [type=2] gmtoff=46800 is_dst=F abbr="+13"</font></div></div><div><br></div><div>All of that looks good. The extra transition is at the end in each case, so the proposed "trim trailing no-op transitions" patch to localtime.c would always do the trick ... correcting the dropped-transition (2147259600) problem for the unfixed zic, and having no effect for the fixed zic. I'm not sure what issue you may have seen with it.</div><div><br></div><div>[One thing I see that has changed in the fixed zic is that the last two "real" transitions are no longer necessarily in the same calendar year. That's not a problem per se, but my future-extension code assumes it. :-( I'll have to fix that.]</div><div><br></div><div>Bradley</div></div></div></div>