[tz] Single source of truth for timezone data

[Paul Eggert]

On 2022-12-07 03:37, Almaz Mingaleev via tz wrote:
> Does that mean that libc APIs will behave differently from whatever
> is using ICU files?

No, as I understand it the idea is to allow automatic rebuilding of the 
timezone-related part of the CLDR/ICU data, whenever a new TZDB version 
is released, without having to wait for updates from CLDR/ICU.

As I understand it, if TZDB releases version X, Android and Apple 
currently wait for ICU/CLDR to release a new version that takes X's 
changes into account. The idea is that we could improve on this by 
developing a procedure that, given a new TZDB release X and an older 
CLDR/ICU release W, would produce a slightly-modified copy W' of the 
CLDR/IDU data that takes X's changes into account, without having to 
wait for ICU/CLDR to produce a new version. Of course when ICU/CLDR get 
around to producing a new version X themselves, you could discard W'.

The main obstacles I see to this are:

* Copyright issues. Unicode, Inc. does not allow people to redistribute 
modified versions of their data files, even if the modifications are 
clearly needed.

* Institutional inertia. ICU/CLDR is big and is unaccustomed to moving 
fast, and timezone info is not high priority for ICU/CLDR.

Although we haven't so far seen any sign of interest here from the 
Unicode, Inc. side, perhaps they'll get around to it if some big 
customers ask them in the right way.

By the way, what bad things would happen if Android and Apple *didn't* 
wait? In other projects I've dealt with, if an upstream program P adds a 
new timezone abbreviation "XYT", downstream distros like Ubuntu can 
immediately ship the new P without waiting for i18n updates. P will 
still work fine in all locales, except that the new "XYT" abbreviation 
(should it be needed) will appear as-is until translators catch up. 
Could Android and Apple do something similar with timezone-related strings?