As I understood the initial email from Alastair McKinstry, there were a couple of options:
A) Change nothing. python-tz continues to use zoneinfo at runtime, as it has in Debian for a long time.
B) Bake in some aliases in python-tz itself. This might be considered similar conceptually (but implementation details would almost certainly vary) to what pytz upstream is doing in gen_tzinfo.py.
Michael Stone proposed: C) Make python-tz depend on tzdata-legacy. On 2025-04-08 12:37, Michael Stone wrote:
On Tue, Apr 08, 2025 at 12:08:05PM -0500, Richard Laager wrote: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?
Since we were asked, I gave my opinion. I agreed with A, with the explicit mention that the user could install tzdata-legacy if they wanted.
If you patch US/Pacific back in manually, then you have two problems: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.
When I was discussing inconsistency, it was in the context of B. That is, if python-tz makes US/Pacific work again without tzdata-legacy (for example, by internally aliasing it to America/Los_Angeles), then that obviously only makes it work in python-tz. Other parts of the system (I gave systemd as an example, since that was my personal experience in the matter) would not work with US/Pacific. I was saying that I think it would be better for the whole system to be consistent, i.e. using one tzdata/zoneinfo database. After all, that is why we have tzdata.
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". 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.
That said, I do recognize that option C has the benefit of pytz everywhere, including Debian, always includes US/Pacific. I know from multiple different points of view (Debian packager, upstream developer, and practicing sysadmin) the potential cons (and the pros) of "Debianisms".
There is a potential slippery slope here... If pytz makes other edits (and the original email says it "pulls down zoneinfo...and edits it", though it's unclear what those edits are), is the expectation that those need to be preserved in Debian as well? What if they conflict with the system tzdata? I realize that decision can be made if/when it actually occurs. I'm just trying to highlight the tension between keeping Debian consistent system-wide and keeping pytz consistent between upstream and Debian.
On the other hand, now that Python (starting with 3.9) includes native support for tzdata/zoneinfo, a major (the only?) reason to use pytz any more is for backwards compatibility (i.e. some Python program needs to work on < 3.9 and >= 3.9). In that case, pytz being inconsistent with the system zoneinfo is already an issue, as it means the available timezones change when you cross the Python 3.9 boundary.
Lastly, I recognize that punting this to the user has cons as well.
For option B, it almost certainly would not be symlinks. It'd be some changes to pytz. For example, adding special cases in timezone() or _case_insensitive_zone_lookup(). The maintenance cost of that is similar, but at least potentially higher.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.
For option C, yes, it's ultimately symlinks that already exist in tzdata-legacy, which is thus not the python-tz maintainer's problem.
-- Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
