[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[Paul Ganssle]

Paul Ganssle  added the comment:

> from practical experience, it is a whole lot better to not deal with 
> timezones in data processing code at all, but instead only use naive UTC 
> datetime values everywhere, expect when you have to prepare reports or output 
> which has a requirement to show datetime value in local time or some specific 
> timezone.

This is not good advice. It is out of date, and has some significant pitfalls. 
See my blog post on the subject: 
https://blog.ganssle.io/articles/2019/11/utcnow.html

If you are working with `datetime` objects that represent time in a specific 
time zone other than the system local zone, you should probably have them carry 
around a tzinfo object.

> Note also that datetime.now() gives you a naive datetime.  From an API 
> consistency standpoint I think it makes sense that datetime.utcnow() gives a 
> naive datetime.

This... is not accurate. `.now()` gives you the local time; to the extent that 
they represent a date in a time zone at all, naïve time zones represent times 
in the *system local time*, which is why it makes sense for `.now()` to default 
to returning naïve time zones. For example, `datetime.now().timestamp()` will 
give accurate information, whereas `datetime.utcnow().timestamp()` will *not* 
(unless your local zone happens to be UTC or equivalent).

> It would actually be confusing (IMO) for it to return an aware datetime.  I 
> can see why you might disagree, but backward compatibility wins in this case 
> regardless.

As evidenced by this thread, the fact that we have some APIs that return naïve 
datetimes generated by a process that treats them as localized datetimes in 
something other than system local times is actually the source of confusion 

That said, from a backwards compatibility point of view, we simply cannot 
change this. It has been proposed many times and it would be a major breaking 
change for almost no reason. The best we can do is to deprecate the offending 
methods and remove them.

There is more information about the challenge that doing this would present in 
this datetime-SIG thread: 
https://mail.python.org/archives/list/datetime-...@python.org/thread/PT4JWJLYBE5R2QASVBPZLHH37ULJQR43/

I am sympathetic to the idea of removing it, but we would probably want to put 
some optimizations in place for `UTC` first, to make the transition more 
seamless in the few places where there are legitimate uses for `utcnow` and 
`utcfromtimestamp`.

> I would argue that PEP20 should win over backward compatibility, in addition 
> to the points I hinted at above, practicality beats purity

PEP 20 contains a bunch of contradictory advice, and it's not really a binding 
document anyway, so it definitely doesn't "win" over anything, but in this case 
you have it backwards. "Purity" would be making a breaking change for the 
purposes of making the function do what a lot of people think it does, but 
doing so would actually be impractical, because it would cause a lot of work 
for people, and create a lot of ambiguity in what people meant when they wrote 
a given line of code. The practical things to do here would be to either do 
nothing (not break anything that works and try and guide people away from using 
`utcnow` — maybe get a linting rule added to `pylint` to warn against it), or 
to deprecate and remove the function.

--

___
Python tracker 

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

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[Tony Rice]

Tony Rice  added the comment:

I would argue that PEP20 should win over backward compatibility, in addition to 
the points I hinted at above, 

practicality beats purity

--

___
Python tracker 

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

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[R. David Murray]

R. David Murray  added the comment:

Note also that datetime.now() gives you a naive datetime.  From an API 
consistency standpoint I think it makes sense that datetime.utcnow() gives a 
naive datetime.  It would actually be confusing (IMO) for it to return an aware 
datetime.  I can see why you might disagree, but backward compatibility wins in 
this case regardless.

--

___
Python tracker 

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

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Hi Tony,

from practical experience, it is a whole lot better to not deal with
timezones in data processing code at all, but instead only use
naive UTC datetime values everywhere, expect when you have to
prepare reports or output which has a requirement to show datetime
value in local time or some specific timezone.

You convert all datetime values into UTC upon input, possibly
store the timezone somewhere, if that is relevant for later reporting,
and then forget about timezones.

Your code will run faster, become a lot easier to understand
and you avoid many pitfalls that TZs have, esp. when TZs are
silently dropped interfacing to e.g. numeric code, databases or
other external code.

There's a reason why cloud code (and a lot of other code, such
as data science code) has standardized on UTC :-)

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

--
nosy: +lemburg

___
Python tracker 

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

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[Tony Rice]

Tony Rice  added the comment:

This enhancement request should be reconsidered.  

Yes it is the documented behavior but that doesn't mean it's the right 
behavior. Functions should work as expected not just in the context of the 
module they are implemented in but the context of the problem they are solving.

The suggested workaround of essentially nesting the specified UTC time via 
datetime.now(timezone.utc) is ugly rather than beautiful, complex rather than 
simple, and nested instead of flat.

The suggestion that now is preferred over isnow loses sight that UTC is not 
like other timezones.

A lot has changed since Python 2.7 was released in 2010. It is the default 
timezone of cloud infrastructure.

--
nosy: +rtphokie

___
Python tracker 

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

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[Paul Ganssle]

Paul Ganssle  added the comment:

@tin utcnow is a semi-deprecated way to get a naive datetime that represents 
the time in UTC. The preferred replacement is to do this:

from datetime import datetime, timezone

datetime.now(tz=timezone.utc)

Note that you can replace "timezone.utc" with *any* time zone. The result will 
be a timezone-aware time zone representing the current time in the time zone 
passed to the function.

I think because there is already a preferred solution available in the standard 
library, there is no need to add a parameter that would make `utcnow` return an 
aware datetime.

--
nosy: +p-ganssle

___
Python tracker 

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

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[Agustin]

Agustin  added the comment:

Hi there, I was wondering if we re-open this issue breaking the backward 
compatibility now?

--
nosy: +tin
versions: +Python 3.9 -Python 2.7, Python 3.2

___
Python tracker 

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

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[Ben Finney]

New submission from Ben Finney ben+pyt...@benfinney.id.au:

=
$ date -u +'%F %T %s %z'
2011-08-16 06:42:12 1313476932 +

$ python -c 'import sys, datetime; now = datetime.datetime.utcnow(); 
sys.stdout.write(now.strftime(%F %T %s %z))'
2011-08-16 06:42:12 1313440932 
=

The documentation for ‘datetime.datetime.utcnow’ says “Return a new datetime 
representing UTC day and time.” The resulting object should be in the UTC 
timezone, not a naive no-timezone value.

This results in programs specifically requesting UTC time with ‘utcnow’, but 
then Python treating the return value as representing local time since it is 
not marked with the UTC timezone.

--
components: Library (Lib)
messages: 142164
nosy: Daniel.O'Connor, bignose, r.david.murray
priority: normal
severity: normal
status: open
title: datetime.datetime.utcnow should return a UTC timestamp
type: feature request
versions: Python 2.7, Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12756
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[R. David Murray]

Changes by R. David Murray rdmur...@bitdance.com:


--
nosy: +belopolsky

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12756
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

[Brett Cannon]

Brett Cannon br...@python.org added the comment:

This is for backwards-compatibility as the UTC object did not come into 
existence until (I believe) Python 2.7. The docs for utcnow() explicitly state 
that if you want a timezone-aware UTC datetime object that you should use now() 
w/ the UTC object passed in.

Now if you would like to have a keyword argument for utcnow() to cause it to 
return a UTC object (e.g., utcnow(aware=True)), that may be a patch that  could 
get accepted as it doesn't break backwards-compatibility if you leave the 
argument out.

--
nosy: +brett.cannon
resolution:  - wont fix
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12756
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com