[tz] Single source of truth for timezone data

enh enh at google.com
Wed Dec 7 18:12:48 UTC 2022


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

it's possible i'm adding more confusion here (in which case tell me and
i'll shut up) because i haven't done any of these updates in many years now
(thanks, almaz and others!), but the problem we had in the past that i
alluded to was that icu4c's date formatting was using its own copy of the
_transition_ data. so format via libc and you get the tzdata transitions
(we're using more-or-less tzcode directly), but format via icu4c (which is
almost every string in the UI) and you'd be using the transition data
bundled with icu.

if that's no longer duplicated, and it's only the _strings_ now, that's
awesome, and nothing i've said (in this mail or my previous one) is
relevant (for which i apologize!).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20221207/5215dc42/attachment.htm>


More information about the tz mailing list