[issue44663] Possible bug in datetime utc

[Petr Viktorin]

Change by Petr Viktorin :


--
components: +Library (Lib) -C API

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44663] Possible bug in datetime utc

[Tim Peters]

Tim Peters  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44663] Possible bug in datetime utc

[Paul Martin]

Paul Martin  added the comment:

The difference between the two is the difference between your local time and 
utc.

datetime.now(timezone.utc)

This returns the current time in utc and is timezone aware. So the timestamp 
can figure out the seconds since epoch taking into account the timezone.


datetime.utcnow()

Returns the current utc time but is not timezone aware. When timestamp  method 
is run, it is interpreted as a local timestamp.

This is explained in the docs but perhaps it should be made clearer that
datetime.utcnow().timestamp() is incorrect and would cause bugs. 

I'm not sure about changing the behaviour of utcnow to return a timezone-aware 
dt as is it could cause hard to detect bugs in existing code. But I did have 
issues recently where I was using utcnow until I went back and read the docs 
and changed to datetime.now(timezone.utc). So it's probably a common trap to 
fall into.

>From the docs:

"
Naive datetime instances are assumed to represent local time #

Note There is no method to obtain the POSIX timestamp directly from a naive 
datetime instance representing UTC time. If your application uses this 
convention and your system timezone is not set to UTC, you can obtain the POSIX 
timestamp by supplying tzinfo=timezone.utc:
timestamp = dt.replace(tzinfo=timezone.utc).timestamp()
or by calculating the timestamp directly:

timestamp = (dt - datetime(1970, 1, 1)) / timedelta(seconds=1)"


Warning Because naive datetime objects are treated by many datetime methods as 
local times, it is preferred to use aware datetimes to represent times in UTC. 
As such, the recommended way to create an object representing the current time 
in UTC is by calling datetime.now(timezone.utc).
"

--
nosy: +primal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44663] Possible bug in datetime utc

[Vedran Čačić]

Vedran Čačić  added the comment:

Would it be possible to change .utcnow to now return a datetime annotated with 
UTC "timezone"? After all, now we have timezone-aware datetimes and the 
convention that naive means local, this behavior might even be considered a bug.

--
nosy: +veky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44663] Possible bug in datetime utc

[Tim Peters]

Tim Peters  added the comment:

> It looks like the difference one would expect from (fast) human input)

Nope, the timestamps in the original report are about 3 hours apart (10808+ 
seconds).

Reports like these are often much clearer if they state the timezone of the 
system they're running on.

Plausible here: as the docs say, `utcnow()` returns a _naive_ datetime - no 
timezone info is attached.

But `.timestamp()`:

"""
Naive datetime instances are assumed to represent local time 
"""

So I _expect_ the results to differ unless the box this is running on uses UTC 
as its local time.

On my box, in native timezone CDT, the two ways are 5 hours apart, which is 
indeed CDT's offset from UTC.

--
nosy: +tim.peters

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44663] Possible bug in datetime utc

[Henk-Jaap Wagenaar]

Henk-Jaap Wagenaar  added the comment:

I don't seem to be able to reproduce this by running this one-liner:

from datetime import datetime, timezone; 
print(datetime.now(timezone.utc).timestamp()); print(datetime.u
tcnow().timestamp());

on 3.9.5. How did you achieve this? It looks like the difference one would 
expect from (fast) human input).

--
nosy: +cryvate

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44663] Possible bug in datetime utc

[Gabriel Costa]

New submission from Gabriel Costa :

>>> datetime.now(timezone.utc).timestamp()
1626556067.054988
>>> datetime.utcnow().timestamp()
1626566875.174921

Should there be a difference between the two modes?

--
components: C API
messages: 397733
nosy: gabhcosta
priority: normal
severity: normal
status: open
title: Possible bug in datetime utc
type: behavior
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com