[tz] Single source of truth for timezone data

[Benjamin Drung]

On Wed, 2022-12-07 at 10:08 -0800, Paul Eggert wrote:
> 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.

Exactly.

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

https://github.com/unicode-org/cldr/blob/main/common/supplemental/metaZones.xml
says "Copyright © 1991-2013 Unicode, Inc." and "For terms of use, see
http://www.unicode.org/copyright.html". This page points to
https://www.unicode.org/license.txt This license looks very similar to
BSD/MIT.

> * 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?

-- 
Benjamin Drung
Debian & Ubuntu Developer