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 in
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..
Perhaps I was unclear, which might have made things worse than having
not said anything at all. So I'll take one attempt at clarifying. The
issue doesn't impact me personally all that much, I don't have strong
feelings, and I recognize that all options have pros and cons.
As I understood the
On Tue, Apr 08, 2025 at 04:50:58PM -0500, Richard Laager wrote:
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'
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.
Hi,
I am not entirely sure, but I think you can probably find those missing
timezones in tzdata-legacy package.
Best,
Ananthu
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
7 matches
Mail list logo
