<div dir="ltr"><div><div>I personally believed rearguard data was going to be kept "forever" as a nod towards backward compatibility. Various downstream APIs and apps that use them probably assume "isDst == summer".</div><div></div></div><div><br></div><div>I suspect downstream folks would value a roadmap of changes like this. Perhaps with a countdown in NEWS to keep it top of mind.</div><div><div><br></div><div><div>More information below about why rearguard / vanguard matters to Android.</div><div></div></div><div><br></div><div>Neil.</div></div><div><br></div><div>-------------</div><div><br></div><div>ICU/CLDR also assume / require rearguard data, and (partly because of this) so does Android. i.e. Android devices will continue to want data updates using rearguard for years to come.<br></div><div><div><br></div><div>Any API that takes a boolean to mean "isDst" / "daylight" or returns a boolean meaning "isDaylight" is affected and will return the opposite behavior after the move to vanguard.</div><div></div></div><div><br></div><div>The problem remains on Android that behavior of APIs has to be supported, but they will change their behavior "overnight" if Android switches from using rearguard to vanguard with a data update. I think there were bugs I fixed that choked on negative DST so at least there won't be crashes. AOSP supports data updates for about 5 years. So, to stop relying on rearguard, a fix would have to be put in place, and then 5 years later Android probably wouldn't need to use rearguard any more.</div><div><br></div><div>To fix this for future releases <i>safely</i>, I think downstream code like Android would need metadata at runtime (preferably mastered by TZDB) that indicates whether a zone ID is one of the ones that has flipped its behavior. Perhaps just a text file list of IDs. With that data, the function could invert the DST boolean at runtime for apps expecting rearguard behavior. This would need to be applied in the implementation of all affected APIs exposed by Android (e.g. ICU4J, java.util.TimeZone, java.time, possibly others). The alternative is to switch and hope for the best.</div><div><br></div><div>AFAIK, nobody is currently working on this on Android, and it would take coordination with ICU to make the "rearguard / vanguard" behavior a runtime behavior change.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 21 May 2021 at 07:23, Paul Eggert via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</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 5/20/21 1:47 PM, Brandon Smith wrote:<br>
> But for the immediate time we are<br>
> still dependent upon rearguard and would respectively ask for your<br>
> support and patience while we continue to work through our necessary<br>
> updates.<br>
<br>
Thanks for the info, and it sounds like we should keep rearguard support <br>
around for a while longer.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div>Google UK Limited<br><br>Registered Office: 6 Pancras Square, London, N1C 4AG<br>Registered in England Number: 3977902</div></div></div></div></div>