Tim Peters <t...@python.org> added the comment: If you want to pursue changing what utcnow() does, python-ideas or python-dev would probably need to be involved. Backward-incompatible changes are very hard sells.
As Paul Ganssle noted here, https://blog.ganssle.io/articles/2019/11/utcnow.html in Python 2, naïve datetimes generally did _not_ get treated as "being in local time", ever. They refused to pretend they had any opinion about time zone, and operations like .timestamp() (just "like", because .timestamp() didn't exist in Python 2) raised an exception when applied to a naïve datetime. Which, IMO, Python 3 should have stuck with. "Naïve time" was never intended to be a synonym for "local time" - or for UTC time - or for any other timezone-aware notion of time. But as Paul also said, if Python 2 had concrete tzinfo classes to begin with, it's a pretty safe bet `utcnow()` would never have existed. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44663> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
