[tz] Single source of truth for timezone data

[enh]

On Thu, Dec 8, 2022 at 12:00 PM Mark Davis ☕️ via tz <tz at iana.org> wrote:

> > 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 only changes that CLDR worries about are ones that would have an
> effect on the choice of 'labels' in formatting dates and times. You can see
> some of those in
> https://unicode-org.github.io/cldr-staging/charts/42/verify/zones/fr.html
> .
>

i think we might be talking at cross-purposes here? i think you're strictly
correct for _cldr_ but i think the questions are really about "the whole of
icu", so the fact (i think!) that icu _does_ need to change
icu4c/source/data/misc/zoneinfo64.txt in response to tzdata changes is
sufficient to be a problem as defined in this thread, even if no new
translations are needed for cldr specifically.


> For example, if a version X of the TZDB has no new zones, and changes to
> the rules for a zone don't require a change to a metazone (e.g. which zones
> it encompasses, or a new metazone), then nothing needs to happen.
>
> Even when a change is needed, in many cases the normal fallback among the
> different types of 'labels' means that people will see something reasonable
> until an implementation upgrades to the latest CLDR.
>
> Moreover, CLDR has become over time more insulated from unnecessary
> instabilities in the TZDB, such as changes in spellings for identifiers,
> changes in the zone1970.tab file (the backward-compatibility aids from the
> TZDB are extremely helpful for that!), etc.
>
> However, just as with the TZDB, there are cases where countries change
> their rules on crazy-short notice, and where CLDR needs to respond quickly.
> We try to do dot releases for those cases, but often translations for zones
> or metazones will lag since we have over 100 languages to manage. Offline,
> people can contact me at mark at unicode.org if they have suggestions for
> improvements.
>
> Mark
>
> [Yoshito is the expert, so he can correct this if some details are off.]
>
>
> On Wed, Dec 7, 2022 at 10:08 AM Paul Eggert via tz <tz at iana.org> 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.
>>
>> 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?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20221208/44d580b1/attachment.html>