"Missing" entries in timezone tables

[Alastair McKinstry]

Hi,

I have an issue with some missing entries in the zoneinfo files in
tzdata that I need to resolve.

I maintain two packages, python-pytz and python-xarray.

python-tz provides a python interface to timezone data;in Debian its
patched to read from zoneinfo rather tha ship its own copy of the data.

python-xarray has in 2025.03.1 now got a unit test that fails because
"US/Pacific" is not present.

Now in python-tz 2025.2  it has changed its build procedure
dramatically; the top-level Makefile pulls down zoneinfo via rsync (ugh)
in build and edits it. In -1 I bypass this as we still apply our patch
to use the official zoneinfo.

But ./gen_tzinfo.py in python-tz adds extra timezones it believes should
be present, including some backwards-compatible entries such as
"US/Pacific". Adding these timezones is possible, but I am loath to
diverge from tzdata..

Any opinions or recommendations?

Regards

Alastair

[Ananthu C V]

Hi,

I am not entirely sure, but I think you can probably find those missing timezones in tzdata-legacy package.

Best,
Ananthu

[Michael Stone]

Post by Alastair McKinstry
But ./gen_tzinfo.py in python-tz adds extra timezones it believes
should be present, including some backwards-compatible entries such as
"US/Pacific". Adding these timezones is possible, but I am loath to
diverge from tzdata..
Any opinions or recommendations?

I'd just depend on tzdata-legacy. I don't really understand why it was
decided to put some names in a separate package, but it's a small one
and if you need compatibility, that's what you need to do.

[Michael Stone]

I got bit (not in pytz) by US/Pacific disappearing, so I understand
the annoyance from the user perspective. However, as that is what has
happening in tzdata, I don't think we should have individual packages
trying to fight that individually/haphazardly.

If you're maintaining a package that itself is trying to maintain
compatibility, what else would you do? As the NEWS related to
tzdata-legacy itself says:

Please install tzdata-legacy in case you need the legacy timezones or to
restore the previous behavior. This might be needed in case the system
provides timezone-aware data over the network (e. g. SQL databases).

1. Things are inconsistent. For example, US/Pacific works in Python,
but not in systemd. (I realize that's the state that upstream pytz is
creating already, but you needn't follow them down this road.)

Why would it not work in systemd? I'd argue that any inconsistency would
be to have debian's pytz needlessly diverge from its expected functionality.

2. You will never know when it's acceptable to remove these, so you'll
feel stuck carrying that forever. (On the other hand, you are just
following upstream pytz, so you can say it's their problem. But, they
will definitely have this same problem of not knowing when to remove
the backwards compatibility.)

Yeah, that's how backward compatibility works. I don't see the problem
at the cost of a few symlinks.

[Michael Stone]

Option C would also keep the whole system consistent. But in that
scenario, installing python-tz indirectly adds system-wide timezone
values. I'm hesitant about that idea; it feels like "spooky action at
a distance".

FWIW, that's how I feel about stuff that worked literally for decades up
and disappearing for no apparent reason, but that's neither here nor there.

As a sysadmin, I could see that leading me to
troubleshoot, "Why does this systemd timer that uses US/Pacific work
on system A, but not system B?" or "Why does `TZ=US/Pacific date` work
on some terminals and not others?" The answer, "Because system A
installed software P that depends on python-tz, so that pulled in
tzdata-legacy.", would feel surprising once I found it. This is
heavily my personal opinion, though.

It's IMO much easier to understand this outcome in a debian context as
dpkg -S US/Pacific
will clarify things pretty quickly.