Title: Document the "gotcha" behaviors in utcnow() and utcfromtimestamp()
Type: enhancement Stage: resolved
Components: Documentation Versions: Python 3.9, Python 3.8, Python 3.7
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: belopolsky, docs@python, epicfaace, miss-islington, p-ganssle
Priority: normal Keywords: patch

Created on 2019-07-02 16:01 by p-ganssle, last changed 2019-09-12 14:59 by p-ganssle. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 15773 merged nanjekyejoannah, 2019-09-09 12:46
PR 16059 merged miss-islington, 2019-09-12 14:43
Messages (5)
msg347148 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-07-02 16:01
Between Python 2 and Python 3, the meaning of a naive datetime underwent a subtle change. Previously a naive datetime was mostly treated as an abstract datetime in the same way a unitless number is treated as an abstract quantity (this is reflected in the current datetime documentation). In Python 3, though, it became more concrete in the sense that rather than just throwing an error whenever you try to do an operation that requires knowing the absolute datetime (e.g. convert between time zones, convert to timestamp, etc), certain operations will succeed with the assumption that naive times represent system local times. This makes `utcnow()` and `utcfromtimestamp()` dangerous, because they create a naive datetime as if the naive datetime represents UTC, but this context is then lost and if you ever use one of these "aware-only" operations (.astimezone, .timestamp, etc), you'll get an unexpected answer.

For example, see this script, executed this with `TZ=America/New_York` on a machine with IANA data installed:

    >>> from datetime import datetime
    >>> dt = datetime.utcfromtimestamp(0)
    >>> dt
    datetime.datetime(1970, 1, 1, 0, 0)
    >>> dt.timestamp()

This happens because EST is 18000s behind UTC, and `.timestamp()` gives a number of seconds after UTC (a concrete, not an abstract time). You get the same gotchas with `utcnow()`.

I'm not sure if actually deprecating `utcnow` and `utcfromtimestamp` is worth it at the moment, but we can definitely start by adding a warning box to `utcnow()` and `utcfromtimestamp()` suggesting that you use the timezone-aware versions of these instead. We may also want to adjust the opening phrasing for the "naive objects" portion of the datetime documentation as well (, to reflect the fact that naive datetimes are no longer purely abstract quantities.
msg351567 - (view) Author: Ashwin Ramaswami (epicfaace) * Date: 2019-09-10 03:27
Why not deprecate them?
msg351884 - (view) Author: miss-islington (miss-islington) Date: 2019-09-11 13:58
New changeset 1a53c785e62e00bad87ae19466c3a32ebcebb915 by Miss Islington (bot) (Joannah Nanjekye) in branch 'master':
bpo-37488 : Document a warning for datetime.utcnow() and utcfromtimestamp() (GH-15773)
msg352189 - (view) Author: miss-islington (miss-islington) Date: 2019-09-12 14:55
New changeset 307c5fe9428b175ff3871a1fdc19bdd7562cfee5 by Miss Islington (bot) in branch '3.8':
bpo-37488 : Document a warning for datetime.utcnow() and utcfromtimestamp() (GH-15773)
msg352192 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-09-12 14:59
Thanks Joannah!
Date User Action Args
2019-09-12 14:59:27p-gansslesetstatus: open -> closed
resolution: fixed
messages: + msg352192

stage: patch review -> resolved
2019-09-12 14:55:51miss-islingtonsetmessages: + msg352189
2019-09-12 14:43:57miss-islingtonsetpull_requests: + pull_request15682
2019-09-11 13:58:45miss-islingtonsetnosy: + miss-islington
messages: + msg351884
2019-09-10 03:27:06epicfaacesetnosy: + epicfaace
messages: + msg351567
2019-09-09 12:46:34nanjekyejoannahsetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request15426
2019-07-02 16:01:38p-gansslecreate