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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12756 ___ ___

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

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