It would probably save some people a lot of time if the documentation of datetime.replace (https://docs.python.org/3/library/datetime.html#datetime.datetime.replace) showed a warning not to use it for setting the timezone on a datetime object or at least that there is a high chance that the result will not be what you expect.

"
If you don't use tz.localize(), but use datetime.replace(), chances are that a historical offset is used instead; tz.localize() will pick the right offset in effect for the given date.
"
More information on the problem can be found here:
https://stackoverflow.com/questions/13994594/how-to-add-timezone-into-a-naive-datetime-instance-in-python

I ran into this problem and it took me quite some time to figure this out. datetime.replace seems more intuitive to use in this case, but since it does not work it might be useful to even link to tz.localize.

That is a specific problem with the third-party library `pytz`, not a standard feature of the datetime module. Using `datetime.replace` is the intended way to set a time zone, see: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html

As of Python 3.6, we've been recommending dateutil.tz instead of pytz, and assuming PEP 615 is accepted ( https://www.python.org/dev/peps/pep-0615/ ), we will have a built in time zone type that supports IANA time zones.

I am going to close this because this is not a bug in CPython, but if you think otherwise feel free to continue using this ticket to make the case.

Thx for this really helpful info.
After reading the article i switched all my code from using pytz to dateutil.tz.