<div dir="ltr">Platform-wise the main issue is that we can no longer use zone.tab<div>to validate our region <-> time zone mapping. In Android time zone</div><div>picker user selects region first, and then there is a list of available</div><div>time zones for that region. The opposite mapping is needed to</div><div>show the region on the same screen when the user has already</div><div>selected a time zone. <br><br>Our biggest concern is consistency not just within Android [1], but</div><div>across everything. So far TZDB is the source of truth in terms of existing</div><div>time zones and how they map to ISO 3166 codes. With the patch applied</div><div>each platform/library might add their own solution to overcome</div><div>that (maybe even create their own fork). Over time they might</div><div>diverge from TZDB.<br><br>Downstream consumers of TZDB time zone IDs (e.g. Android, ICU,</div><div>OpenJDK, geonames, timezone-boundary-builder, etc.) and their users,</div><div>rightly or wrongly, associate time zone IDs with countries.<br><br>More precisely, it's usually not the IDs themselves they associate, it's the</div><div>metadata that other projects have associated with the IDs (e.g. exemplar</div><div>locations, display names like "British Standard Time") assuming they</div><div>are country specific.<br><br>We think the current state of TZDB is likely to lead to the kind of problem</div><div>that Stephen pointed out in <a href="https://mm.icann.org/pipermail/tz/2021-May/030142.html">https://mm.icann.org/pipermail/tz/2021-May/030142.html</a></div><div>and support something like his "tzdb should provide is a full time-zone</div><div>with history (not a Link) for each region identified by an ISO-3166-1 code".<br><br>With TZDB abdicating responsibility for the mapping between time zone</div><div>and ISO code, the problem doesn't go away, it just gets pushed to the many</div><div>downstream projects who have no choice but to work the way users have</div><div>come to expect.<br><br>From an Android perspective (ignoring other platforms/libraries/etc) the patch</div><div>just adds an extra maintenance burden and creates inconsistency risks.<br><br>[1] There are several time zone related APIs available on Android:</div><div>java.util.TimeZone, java.time package, ICU4C/ICU4J, C API provided by</div><div>bionic(Android’s implementation of libc). bionic and java.util.TimeZone read</div><div>TZif file, java.time is based on ICU4J, ICU uses its own .dat file.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Sept 2021 at 22:30, 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 9/13/21 6:33 AM, Almaz Mingaleev via tz wrote:<br>
> If 2021b comes out tomorrow, without the patch being reverted that<br>
> would be a lot of work for Android<br>
<br>
We do expect some progress on this issue shortly. In the meantime please <br>
don't worry; 2021b is not coming out tomorrow.<br>
<br>
By the way, what work would be needed for Android? Can you point to <br>
Android code that would need changing, for example? My impression is <br>
that the patch has little effect on Android users; if I'm wrong, it'd be <br>
nice to know details.<br>
</blockquote></div>