[tz] Vanguard vs. "main" vs. rearguard

Neil Fuller nfuller at google.com
Mon Jun 7 16:21:41 UTC 2021


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

I suspect downstream folks would value a roadmap of changes like this.
Perhaps with a countdown in NEWS to keep it top of mind.

More information below about why rearguard / vanguard matters to Android.

Neil.

-------------

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.

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.

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.

To fix this for future releases *safely*, 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.

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.

On Fri, 21 May 2021 at 07:23, Paul Eggert via tz <tz at iana.org> wrote:

> On 5/20/21 1:47 PM, Brandon Smith wrote:
> > But for the immediate time we are
> > still dependent upon rearguard and would respectively ask for your
> > support and patience while we continue to work through our necessary
> > updates.
>
> Thanks for the info, and it sounds like we should keep rearguard support
> around for a while longer.
>


-- 
Google UK Limited

Registered Office: 6 Pancras Square, London, N1C 4AG
Registered in England Number: 3977902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20210607/3961e5b3/attachment.html>


More information about the tz mailing list