This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients cryvate, gabhcosta, primal, tim.peters, veky
Date 2021-07-19.00:16:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1626653760.6.0.854546545588.issue44663@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2021-07-19 00:16:00tim.peterssetrecipients: + tim.peters, veky, cryvate, primal, gabhcosta
2021-07-19 00:16:00tim.peterssetmessageid: <1626653760.6.0.854546545588.issue44663@roundup.psfhosted.org>
2021-07-19 00:16:00tim.peterslinkissue44663 messages
2021-07-19 00:16:00tim.peterscreate