[tz] Single source of truth for timezone data

[Almaz Mingaleev]

On Wed, 7 Dec 2022 at 18:08, Paul Eggert <eggert at cs.ucla.edu> 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.
>

I've meant how things work now. My concern was around these lines:

> Since the icu
> project lacks behind the tzdata release by hours up to days, Ubuntu has
> to update tzdata twice (first the tzdata release, then the icu update).

Between these updates you will get different answers from different APIs.


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

ICU and CLDR versions are bumped once a year. We do not wait for a new
version, but for patches only.


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


On Android we cannot not wait. As I mentioned there are several API
surfaces and being consistently wrong about _new_ changes is better
than having different answers within the platform. Also, it takes time to
prepare and rollout these updates, so not waiting will only cause
disruption,
extra work, and bugs from confused users.


>
> new timezone abbreviation "XYT", downstream distros like Ubuntu can
> immediately ship the new P without waiting for i18n updates. P will


It is not a problem if a distro ships it, it is a problem if this new stuff
leaks
to the external world. It would be naive to expect from a user base of a
service
to have up-to-date time zone data even after a month after TZDB release.


>
> still work fine in all locales, except that the new "XYT" abbreviation
> (should it be needed) will appear as-is until translators catch up.


It is not translations that we are waiting for, but changes like [1
<https://github.com/unicode-org/icu/pull/2261/files>]. Recent
time zone changes were short notice ones and ICU team (thanks Yoshito and
others!)
did these changes very quickly.

[1] https://github.com/unicode-org/icu/pull/2261/files


> 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/80c64896/attachment.html>