[issue40136] add warning to datetime.replace documentation to not use it for setting tzinfo unless UTC or None
New submission from Benedikt Bleimhofer <benedikt.bleimhofer@gmail.com>: 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-naiv... 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. ---------- assignee: docs@python components: Documentation messages: 365469 nosy: Benedikt Bleimhofer, docs@python priority: normal severity: normal status: open title: add warning to datetime.replace documentation to not use it for setting tzinfo unless UTC or None type: enhancement _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue40136> _______________________________________
Paul Ganssle <p.ganssle@gmail.com> added the comment: 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. ---------- nosy: +p-ganssle resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue40136> _______________________________________
Benedikt Bleimhofer <benedikt.bleimhofer@gmail.com> added the comment: Thx for this really helpful info. After reading the article i switched all my code from using pytz to dateutil.tz. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue40136> _______________________________________
Paul Ganssle <p.ganssle@gmail.com> added the comment: 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. ---------- nosy: +p-ganssle resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue40136> _______________________________________
Benedikt Bleimhofer <benedikt.bleimhofer@gmail.com> added the comment: Thx for this really helpful info. After reading the article i switched all my code from using pytz to dateutil.tz. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue40136> _______________________________________
participants (2)
-
Benedikt Bleimhofer -
Paul Ganssle