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