Paul Ganssle

Given these results and the fact that people don't seem to have a great grasp on what this is supposed to do, let's push this feature to 3.12 to try...

I object to the idea that using `Z` unconditionally is "the right thing", but also there are several logistical problems that make the idea of changing the default behavior a...

I think this is a good idea generally. I'm inclined to _not_ make it its own method if at all possible, and to avoid baking in the assumption that `datetime`...

@diabonas I am not a maintainer of this, but I think @stub42 has said in the past that he doesn't plan to support version 2+ files. In Python 3.9, we...

Probably the most prudent option for Arch Linux is to deploy `-b fat` tzdata for some time longer. The difference between the two is that the `-b slim` version has...

> Hopefully I or someone can prove @pganssle wrong and it can be fully backwards-compatible. To be clear, you can write a version of `pytz` that is fully backwards-compatible, it...

> I'm sure keeping pytz's API and output identical to its current behavior will be fine and no one is going to complain. :) Yes, being backwards and forwards compatible...

> Work on fixing this should probably go into Python core, adding a tzfile implementation that supports the modern format. For anyone finding this thread later: this has been done....

> The DST offset is somewhat ill defined, as it is the difference between the wallclock time and the 'standard' offset. The 'standard' offset can be debatable. The offset before...

Hm.. My plan was to actually backport as much of the pure Python logic from `zoneinfo` as possible into `dateutil`, but these changes do seem fairly minimal. That said, there...