This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Using datetime.datetime.utcnow().timestamp() in Python3.6.0 can't get correct UTC timestamp.
Type: behavior Stage: resolved
Components: Extension Modules Versions: Python 3.6
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Han Shaowen, ned.deily, tim.peters
Priority: normal Keywords:

Created on 2018-04-17 05:20 by Han Shaowen, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (10)
msg315377 - (view) Author: Han Shaowen (Han Shaowen) Date: 2018-04-17 05:20
What I am talking is like:

Python 3.6.0 (default, Feb 28 2018, 15:41:04)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> from datetime import datetime
>>> time.time()
>>> datetime.utcnow().timestamp()

Apparently, give me right unix timestamp while utcnow().timestamp() doesn't.

Fellas what do you think about this?
msg315413 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2018-04-17 20:49
Are you seeing the same issue on Python 3.6.5?
msg315414 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2018-04-17 20:50
And we do have women on the team, so please minimize the "fellas" comments.
msg315415 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-04-17 20:50
I am not sure I understand what behavior you are expecting.  But is documented as returning "the current local date and time" (assuming no tx= argument is provided) while datetime.utcnow() returns "the current UTC date and time".  So I would expect the two to provide a similar value only if your system/process local time zone is set to UTC.  I'm guessing the time zone in effect when your examples were run was 8 hours ahead of UTC:

>>> (1523942165.202865 - 1523913372.362377) / (60*60)
msg315418 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2018-04-17 20:58
I agree this isn't a bug (and it was right to close it).  I expect the OP is confused about what the `.timestamp()` method does, though.  This note in the docs directly address what happens in their problematic `datetime.utcnow().timestamp()` case:

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)
msg315419 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-04-17 21:03
Tim, do you think the docs should be changed and, if so, which sections?  If you dictate, I'll type!
msg315421 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2018-04-17 21:15
Ned, I think this one is more the case that the OP didn't read the docs ;-)

That said, there's a level of complexity here that seemingly can't be reduced:  the distinctions between the `datetime` and `time` modules' views of the world, and between `datetime`'s notions of `aware` and `naive` datetime objects.  Those are general distinctions that apply all over the place, not just in a method or two's docs.

Given that those are understood, the OP's results "are obvious".  But it takes some work for users to get to that point, and best I can tell the current docs have been successful at helping users get there - but they do have to do the work of reading them thoughtfully.
msg315433 - (view) Author: Han Shaowen (Han Shaowen) Date: 2018-04-18 03:01
Guys, what I said is the doc in help(datetime.timestamp) is 'Return POSIX timestamp as float.' So I assumed it is irrelevant to time zone, considering POSIX timestamp's definition. If it is then and datetime.utcnow should return the same timestamp. But return a correct timestamp which I checked in the website but datetime.utcnow().timestamp did not.

msg315434 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2018-04-18 03:11
docstrings give brief statements intended to jog your memory; they're not intended to be comprehensive docs.  Read the actual documentation and see whether you're still confused.  When you "assumed it is irrelevant to time zone", that was your _assumption_, which the actual docs would have clarified.

The whole story simply can't be told here without docs that make the distinction between "naive" and "aware" datetime objects, and the connection to what your platform's C mktime() function does about your local time zone.  The brief docstring is correct that a POSIX timestamp is returned (a count of seconds from the UTC epoch).  But how that relates to the datetime object requires reading the docs, not blind guessing ;-)
msg315435 - (view) Author: Han Shaowen (Han Shaowen) Date: 2018-04-18 03:27
Hohoho, I found the full-version doc. This issue over. Thanks Tim, Ned and Brett. And sorry about something improper I said, I respect female Pythonista.
Date User Action Args
2022-04-11 14:58:59adminsetgithub: 77474
2020-03-15 16:09:08belopolskylinkissue39970 superseder
2018-04-18 03:27:51Han Shaowensetmessages: + msg315435
2018-04-18 03:11:33tim.peterssetmessages: + msg315434
2018-04-18 03:01:35Han Shaowensetmessages: + msg315433
2018-04-17 21:15:05tim.peterssetmessages: + msg315421
2018-04-17 21:03:48ned.deilysetmessages: + msg315419
2018-04-17 20:58:56tim.peterssetnosy: + tim.peters
messages: + msg315418
2018-04-17 20:50:45ned.deilysetstatus: open -> closed

nosy: + ned.deily, - brett.cannon, belopolsky
messages: + msg315415

resolution: not a bug
stage: resolved
2018-04-17 20:50:05brett.cannonsetmessages: + msg315414
2018-04-17 20:49:39brett.cannonsetnosy: + brett.cannon, belopolsky
messages: + msg315413
2018-04-17 05:20:37Han Shaowencreate