On 2022-12-08 13:50, Paul Eggert via tz wrote:

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/+/ea3e0ece71974c1d...> * 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.

Launchpad shows Ubuntu 22.10 Proposed kinetic-proposed/main tzdata 2022g, also jammy- and focal-proposed, released Dec 1 when the maintainer started this thread. You could add the -proposed source to apt sources, and/or set apt preferences to only use it for tzdata, as the -proposed source seems to be first to get ICU updates in tzdata package release yyyyX-0ubuntu0.MM.mm.1; -updates and -security follow. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry