[tz] Single source of truth for timezone data

[Paul Eggert]

On 2022-12-08 05:24, Almaz Mingaleev wrote:

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

Sorry, I'm not following. When Ubuntu ships a new tzdata package then 
surely that has "leaked" to the outside 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.

In the past I've gotten my Ubuntu systems updated within 24 hours of a 
tzdata release, simply by applying patches as usual from Ubuntu. But as 
Benjamin indicates, this is not happening with 2022g. I just now checked 
for updates and I'm still stuck on 2022f. So from my point of view, 
Ubuntu is slow in this case - instead of taking less than a day, it's 
taking more than a week.


> being consistently wrong about _new_ changes is better
> than having different answers within the platform.

As a Ubuntu user, I'd prefer tzdata to be up-to-date even though ICU is 
out-of-date, over having both tzdata and ICU out-of-date. Of course 
Ubuntu differs from Android in that most apps use tzdata not ICU. Still, 
I'm a bit curious what end-user-visible problems would occur on Android 
and/or Ubuntu if tzdata leads ICU slightly. I know you've seen problems, 
but were they end-user problems or just test-case problems? On Ubuntu 
various other copies of tzdata (e.g., Python's) can be slightly out of 
date too, but this doesn't seem to be much of an issue.

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

Thanks, I didn't know that.

Here's a timeline I see for the latest Mexico change:

* 2022-11-28 17:00 UTC - news article published announcing the change 
(which is not official yet, I think) 
<http://puentelibre.mx/noticia/ciudad_juarez_cambio_horario_noviembre_2022/>

* 2022-11-29 03:55:31 UTC - tz mailing list notified 
<https://mm.icann.org/pipermail/tz/2022-November/032365.html>

* 2022-11-29 17:42:29 UTC (14 hours after notification) - tzdb 2022g 
announced 
<https://mm.icann.org/pipermail/tz-announce/2022-November/000076.html>

* 2022-11-29 18:23:41 UTC (less than an hour after tzdb 2022g 
announcement) tzdata 2022g-r0 released for Alpine Linux 
<https://pkgs.alpinelinux.org/package/edge/main/x86/tzdata>

* 2022-11-30 07:06 UTC (7 hours after tzdb 2022g announcement) - tzdata 
2022g-1 released for Arch Linux 
<https://archlinux.org/packages/core/x86_64/tzdata/>

* 2022-12-01 03:08:08 UTC (33 hours after tzdb 2022g announcement) - 
abovementioned ICU patch committed

* 2022-12-01 12:38:06 UTC (9 hours after ICU patch committed) - Ubuntu 
patch committed 
<https://launchpad.net/ubuntu/+source/tzdata/2022g-0ubuntu0.22.10.1>

* 2022-12-05 (4 days after ICU patch committed) - Red Hat Enterprise 
Linux fix available to users 
<https://access.redhat.com/errata/RHBA-2022:8785>

* 2022-12-07 (6 days after ICU patch committed) - Android patch 
committed 
<https://android.googlesource.com/platform/system/timezone/+/ea3e0ece71974c1df741b1b0d7789682d6d40dea>

* now (a week after ICU patch committed) - my Ubuntu workstation is 
still not updated.

We should be able to do better than this; that is, be more like Alpine 
or Arch Linux, or at least more like RHEL (though I see that Fedora 
still hasn't released 2022g...). Though ICU is part of the problem (as 
is tzdb itself :-), most of the delay seems to be occurring even after 
ICU patches are applied.