[tz] Single source of truth for timezone data

[Paul Eggert]

On 2022-12-09 15:08, Benjamin Drung wrote:
> 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.

I remember writing to this list about the speed of Ubuntu updates at 
least once. After some searching today, I found that after the 2015f 
release was announced August 11, 2015 at 04:37:39 UTC, I wrote on August 
13 at 15:01:16 UTC that my Ubuntu workstation was already updated. See:

https://mm.icann.org/pipermail/tz/2015-August/022594.html

I didn't do anything special; I simply ran updates. So it sounds like 
the SRU process has had some sort of exception in the past for tzdata, 
and it suggests that Ubuntu could continue to have this exception.

That said, running updates is complicated in Ubuntu as there are several 
ways to do it. On the Ubuntu 22.10 workstation I'm typing this on, if I 
click on Activities and search for "update" I get three different 
Ubuntu-supplied GUI icons, labeled "Software Updater", "Software & 
Updates", and "Ubuntu Software"; each can update tzdata. I can also do 
command-line updates with shell commands like "apt" or terminal-window 
commands like "aptitude". These alternate ways of doing updates 
typically do not agree, so although I did just update as usual in 2015, 
perhaps I used a different update procedure than the one you're thinking 
about. (Back in 2015 I was probably using "aptitude".)


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

I suspect there are several packages other than python3-pytzdata that 
have such lists. Although I by no means have a lot of packages installed 
on my workstation, I just now ran the command

    grep -rl Africa/Casablanca /usr /snap

and found several files that mentioned this string (which is almost 
surely derived from tzdata). Here are three:

   /usr/share/liblangtag/common/bcp47/timezone.xml
   /usr/lib/thunderbird/libxul.so
   /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.6

from the liblangtag-common, thunderbird, and libqt5core5a packages.

Also, due to Ubuntu's use of snaps there are multiple copies of tzdata 
on my workstation, not all of which agree. For example, the shell command:

   find /usr /snap '(' -name right -o -name posix ')' -prune -o -name 
Ojinaga -type f -print

outputs six file names, representing two distinct time zone histories 
for America/Ojinaga, as shown by the following command. Although I hope 
apps never use the obsolete Ojinaga files, I don't know how to check 
this - nor do I know why Ubuntu keeps around the obsolete files given 
the desire that there be just one copy of tzdata in Ubuntu.

$ diff -u <(zdump -i /usr/share/zoneinfo/America/Ojinaga) <(zdump -i 
/snap/core20/1695/usr/share/zoneinfo/America/Ojinaga) | head -n 17
--- /dev/fd/63	2022-12-10 12:28:58.449876843 -0800
+++ /dev/fd/62	2022-12-10 12:28:58.449876843 -0800
@@ -1,5 +1,5 @@

-TZ="/usr/share/zoneinfo/America/Ojinaga"
+TZ="/snap/core20/1695/usr/share/zoneinfo/America/Ojinaga"
  -	-	-065740	LMT
  1922-01-01	00	-07	MST
  1927-06-11	00	-06	CST
@@ -60,4 +60,958 @@
  2021-03-14	03	-06	MDT	1
  2021-11-07	01	-07	MST
  2022-03-13	03	-06	MDT	1
-2022-10-30	02	-06	CST
+2022-11-06	01	-07	MST
+2023-03-12	03	-06	MDT	1
+2023-11-05	01	-07	MST