Comment 2 for bug 1884458

The stackoverflow question already has an answer for this. It's because pytz does not accurately handle the constructor for `datetime` with the`tzinfo` parameter. It will often give the wrong UTC offset. We need to use the `timezone.localize()` method instead.

This little wart in the pytz API confuses people frequently. I have to consult the pytz documentation every time I use it. The fact that it confuses Paul Eggert makes me feel a little better.

I don't fully understand why pytz has this limitation, I think it has something to do with the API exposed by the `datetime` class, and the way pytz caches the DST transitions. This article by the author of `dateutil` has a lot more info: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html. The newer `dateutil` package does not have this problem.

By the way, both pytz and dateutil seems to have numerous inaccuracies with regards to the DST offset for various timezones (I recall that the negative -1:00 offset for Europe/Dublin is one of them). Both packages currently support only 32-bit transitions, until year 2038. In addition, dateutil has special problems for transitions in the year 2037, while pytz handles those properly. I have not filed bugs against either packages for the DST offset bugs: The pytz package seems to be in maintenance mode. The large backlog of bugs on the `dateutil` package indicates that the maintainer is too busy.