Why the difference between datetime.datetime.now().timestamp() and datetime.datetime.utcnow().timestamp()?

Question

As I understand the seconds since Unix epoch (1970-01-01 00:00:00 UTC) should be the same everywhere around the globe, since it is fixed to UTC.

Now, if you are in a timezone with some hours +/- UTC, why do you get different timestamps if you do this (+2 hours in my case)

>>> datetime.datetime.utcnow().timestamp()
1523622844.637763
>>> datetime.datetime.now().timestamp()
1523630048.558158

If you account for the time it took me to run the 2nd line of code, you get to the conclusion that there is a 7200 seconds (2 hrs) difference between the two timestamps. Shouldn't these timestamps be time zone unaware?

floatingpurr · Accepted Answer · 2018-04-13T15:17:04.787

3

From the docs:

datetime.now(): returns the current local date and time.
datetime.utcnow(): returns the current UTC date and time [...]. This is like now(), but returns the current UTC date and time, as a naive datetime

Just an example:

Offset

In [1]: datetime.datetime.now()
Out[1]: datetime.datetime(2018, 4, 13, 17, 8, 4, 457551)

In [2]: datetime.datetime.utcnow()
Out[2]: datetime.datetime(2018, 4, 13, 15, 8, 5, 385598)

No offset

In [3]: datetime.datetime.now(tz=pytz.utc)
Out[3]: datetime.datetime(2018, 4, 13, 15, 8, 59, 590874, tzinfo=<UTC>)

In [4]: datetime.datetime.utcnow()
Out[4]: datetime.datetime(2018, 4, 13, 15, 9, 1, 494370)

edited Apr 13 '18 at 15:17

answered Apr 13 '18 at 15:01

floatingpurr

7,749
9
46
106

1

Thank you, `pytz` seems to solve my misunderstanding of timezone awareness. – TeXnophobe Apr 13 '18 at 15:33
Good! Feel free to accept such an answer it solved :) – floatingpurr Apr 13 '18 at 15:47

score 1 · Answer 2 · answered Apr 13 '18 at 15:09

datetime.now() and utcnow() are TZ-unaware (that is, the default tzinfo is None).

From the documentation (https://docs.python.org/3.6/library/datetime.html#datetime.datetime.timestamp):

Naive datetime instances are assumed to represent local time

And, crucially:

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)

In other words, in your example the correct value for timestamp is the second one (using now()).

I think this is the correct answer and drives to the point that timestamp is not the POSIX timestamp (seconds since 1970,1,1UTC) as stated in the python documentation. It is the time since 1970,1,1 of the timezone in the datetime object (tzinfo). Yes, you can force your datetime to be UTC by making your datetime be in the UTC Timezone, but that is now your datetime does not represent the current time. — DrBB, Jan 31 '23 at 23:09

score 0 · Answer 3 · edited Apr 13 '18 at 15:34

The BIOS of your computer may be set to local time instead of UTC time. In general for systems running unix like operating systems UTC time is the norm. For systems running Windows local time is the norm. .now() is should display the same time you see displayed on the clock on your computer, while .utcnow() is NOT aware of your timezone offset set in your OS and it displays UTC date and time.

Why the difference between datetime.datetime.now().timestamp() and datetime.datetime.utcnow().timestamp()?

3 Answers3