[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "Missing" entries in timezone tables



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.

I looked at the patches in the package. Am I correct in understanding that python-tz loads from zoneinfo at runtime?

If so, then I think you should leave things alone. If the user needs things like US/Pacific, they can install tzdata-legacy and get it system-wide.

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

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

On 2025-04-08 11:14, Michael Stone wrote:
On Tue, Apr 08, 2025 at 06:42:43AM +0100, Alastair McKinstry wrote:
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.


--
Richard

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


Reply to: