Repository navigation
datetime.utcnow() should return a timezone aware datetime #90477
Description
| BPO | 46319 |
|---|---|
| Nosy | @abalkin, @vadmium, @pganssle, @rtphokie |
| Superseder |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2022-01-10.03:21:41.082>
created_at = <Date 2022-01-09.18:37:40.462>
labels = ['type-bug', 'library', '3.9', '3.10', '3.11']
title = 'datetime.utcnow() should return a timezone aware datetime'
updated_at = <Date 2022-01-10.03:21:41.081>
user = 'https://github.com/rtphokie'bugs.python.org fields:
activity = <Date 2022-01-10.03:21:41.081>
actor = 'p-ganssle'
assignee = 'none'
closed = True
closed_date = <Date 2022-01-10.03:21:41.082>
closer = 'p-ganssle'
components = ['Library (Lib)']
creation = <Date 2022-01-09.18:37:40.462>
creator = 'rtphokie'
dependencies = []
files = []
hgrepos = []
issue_num = 46319
keywords = []
message_count = 3.0
messages = ['410160', '410179', '410183']
nosy_count = 4.0
nosy_names = ['belopolsky', 'martin.panter', 'p-ganssle', 'rtphokie']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '12756'
type = 'behavior'
url = 'https://bugs.python.org/issue46319'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']
Activity
rtphokie commentedon Jan 9, 2022
returns a timezone naive datetime, this is counter-intuitive since you are logically dealing with a known timezone. I suspect this was implemented this way for fidelity with the rest of datetime.datetime (which returns timezone naive datetime objects).
The workaround (see below) is to replace the missing tzinfo.
Recommendation:
By default datetime.datetime.utcnow() should return a timezone aware datetime (with tzinfo of UTC of course) or at least offer this behavoir as an option,
e.g.:
Workaround:
dt = datetime.utcnow().replace(tzinfo=timezone.utc)
vadmium commentedon Jan 10, 2022
Perhaps this is a duplicate of bpo-12756?
pganssle commentedon Jan 10, 2022
Yes, this is the documented behavior, including a warning against using UTC now in the documentation!
There is some possibility of removing utcnow entirely as an "attractive nuisance", but I suspect that this will lead to much consternation and hand-wringing, and there are some legitimate uses for
utcnow, so I haven't made it a high priority to have that particular fight...