[tz] Single source of truth for timezone data

Fri Dec 9 23:08:33 UTC 2022

On Thu, 2022-12-08 at 12:50 -0800, Paul Eggert wrote:
> 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.

Ubuntu has as stable release update (SRU) process [1]. The process
includes letting the update age in -proposed for at least seven days.
That hasn't changed since the beginning in 2006. So I wonder how you get
the updates within 24 hours. Feel free to start a discussion with the
SRU team to reduce the ageing time for tzdata updates that are urgent.
The technical minimum would be a few hours (for the package build and to
run all autopkgtest).

Side note: Ubuntu uses phased updates which means that updates reach the
users step by step. The tzdata updates are copied to -security [2] and
therefore all users should get them without phasing.

The update for 2022g is tracked in bug #1998321 [3].

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[2] https://wiki.ubuntu.com/StableReleaseUpdates#tzdata
[3] https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1998321

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

There should be no copies of tzdata in Ubuntu. All software packages
should only rely on tzdata. Please let me know if you find any. The only
problematic package that I know is python3-tz which includes a hard
coded list of time zone names [4]. Python uses the data from the tzdata
package.

[4] https://bugs.launchpad.net/ubuntu/+source/python-tz/+bug/207604

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

Let me enhance that timeline.

> * 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-11-30 10:21 UTC - Ubuntu tzdata update ticket created
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1998321

* 2022-11-30 13:42 UTC - tzdata 2022g-0ubuntu1 uploaded to Ubuntu 23.04
(lunar)

* 2022-11-30 14:46 UTC - tzdata 2022g-0ubuntu0.22.10.0 uploaded to
Ubuntu 22.10 (kinetic-proposed)

* 2022-11-30 16:35 UTC - tzdata 2022g-0ubuntu0.22.04.0 uploaded to
Ubuntu 22.04 (jammy-proposed)

* 2022-11-30 17:58 UTC - tzdata 2022g-0ubuntu0.20.04.0 uploaded to
Ubuntu 20.04 (focal-proposed)

* 2022-11-30 19:08 UTC - tzdata 2022g-0ubuntu0.18.04 uploaded to Ubuntu
18.04 (bionic-proposed)

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

* 2022-12-01 12:30 UTC - tzdata 2022g-0ubuntu2 with ICU update uploaded
to Ubuntu 23.04 (lunar)

> * 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-01 12:50 UTC - tzdata 2022g-0ubuntu0.22.04.1 with ICU update
uploaded to Ubuntu 22.04 (jammy-proposed)

* 2022-12-01 12:54 UTC - tzdata 2022g-0ubuntu0.20.04.1 with ICU update
uploaded to Ubuntu 20.04 (focal-proposed)

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

-- 
Benjamin Drung
Debian & Ubuntu Developer