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

[Neil Fuller]

I think you're correct it would have to be more complicated: I was thinking
about Dublin, not Windhoek.

The main point I'd make about Android challenges associated with TZDB is...

When TZDB makes a fundamental change (rearguard or other recent proposals),
Android has to formulate a plan for:

(1) how to arrange things for new apps on new devices to move things
forward (which requires a good understanding of where TZDB is going)
(2) how to ensure old apps still get old behavior on new devices (which
requires a way to continue to provide that old behavior)
(3) how to keep existing devices running with latest TZDB data (and which
do not take code changes) until they drop out of the support window. This
can take years (which requires a degree of stability of file formats /
conventions or Android risks user-facing breakages / changes)

Where possible, Android also doesn't want to master too much of its own
data and would prefer to adopt changes on its own, usually yearly, major
release schedule.

AFAIK, this is possible with things like the "slim" format: slim *probably*
can't be used on existing devices. Because Android typically doesn't get to
update code for TZDB updates, only data, it will stick with the "fat"
format for existing devices.

Android is downstream of various open source projects that themselves are
downstream of TZDB. If TZDB *doesn't* master information, and something is
left to each project to work out, they could jump in different directions.
e.g. if two projects want country-specific zone IDs, and they don't come
from TZDB, then there's a risk of one of them "inventing" (should the need
arise) Europe/Glasgow as "the zone for Scotland", and another inventing
Europe/Edinburgh to fill the same role. There goes our interoperability.
Different projects going in different directions was a risk with rearguard,
too, but everything we currently care about (ICU and our own code) stuck
with rearguard so we thankfully haven't had to deal with it.

I appreciate these problems are well outside of your scope. Until recently
I was handling TZDB updates on the Android side, so I may have an unusual
perspective among readers of this list.

As always, thanks for the hard work.

Neil.


On Mon, 7 Jun 2021 at 18:01, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 6/7/21 9:21 AM, Neil Fuller wrote:
>
> > 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.
>
> Surely it'd have to be more complicated than that, as a single Zone can
> have negative DST some years, and positive DST other years. See
> Africa/Windhoek, for example.
>
> But perhaps I'm not understanding the problem correctly, as I don't see
> why tzdb would need to maintain a separate set of data for this issue.
> Android libraries could have a flag (or multiple versions, or however
> Android folks like to do software changes) controlling whether an
> application can tolerate negative DST. If the flag says "negative DST is
> OK", the libraries can pass through data unscathed. If the flag says "I
> don't want to see negative DST", then whenever the underlying data says
> DST is negative, the Android library can swap standard and daylight time
> and give the swapped info to the app. As I understand it, Android
> libraries are already doing the latter; if so, all that needs to be
> added is a flag so that they can do the former.
>
> Anyway, I appreciate the info about why rearguard support will be needed
> for quite some time.
>
>

-- 
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/20210609/1b9c45ba/attachment.html>