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

Re: "Missing" entries in timezone tables



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

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.

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.


Reply to: