Hi,

Thanks for taking time to reply my question.

I suppose the title I put was a bit confusing.

And the recommended way to generate time in UTC does solve this issue, in Python.

However the message I was trying to convey is, the behavior of timestamp() is one action too much from my point of view.

Say, for example, if I'm sending data generated on my local machine (in CST time) to someone else, and for easy comparison and precision I used `datetime.datetime.now().timestamp()` as the value of time fields. I would naturally think that the timestamp() function returned the timestamp of my local time. And if the person who received the data, instead of using Python, used Node.js to import those timestamps, and told by me that the timestamps were in CST time. Then he/she will get the wrong time since those timestamps were actually in UTC.
As Scott Mayer, the author of Effective C++, once said, "APIs should be easy to use correctly and hard to use incorrectly", timestamp() functions from my point of view did one thing too much, it shouldn't shift any datetime object that it was fed into.
And in the documentation of datetime.timestamp(), there is no warning about this behavior, only a note on getting the UTC time. It only says "Return POSIX timestamp corresponding to the datetime instance". From my understanding POSIX timestamp is the time elapsed since epoch, not time elapsed -8 hours on CST timed machines since epoch.

By it's nature, timestamps couldn't and shouldn't incorporate any timezone information, when only presented with a naive datetime, program should only convert it to whatever datetime that timestamp represents, rather than thinking that the machine is in some timezone and shifts it by some time and then converts it.

Sorry if what I wrote does not make sense, the reason for me to use utcnow() is just to demonstrate, from my point of view utcnow() or utcfromtimestamp() did nothing wrong, but the problem lies with the timestamp() and fromtimestamp() functions' extra behavior.

Another example is, say, the current unix epoch is 1584330809, when I fed it into Python on my local machine, I get:
>>> datetime.datetime.fromtimestamp(1584330809)
datetime.datetime(2020, 3, 16, 11, 53, 29)

when I fed it into Node.js, I get:
> new Date(1584330809*1000)
2020-03-16T03:53:29.000Z

From my point of view, the Node's behavior is much more natural and intuitive.

since we didn't know what timezone 1584330809 is in, the returned datetime should be just how many seconds elapsed since epoch, not my local time of the machine.