Is Python's time.time() timezone specific?

Question

Apologies for asking too basic question but I couldn't get it cleared after reading docs. It just seems that I am missing or have misunderstood something too basic here.

Does calling time.time() from different timezones, at the same time produce different results? This maybe comes down to definition of epoch, which on the docs (and on my not-so-deep search on the Internet), has no mentions of the timezone.

Also, suppose time.time() has been called from places with different timezones, and converted to UTC datetimes on their machines, will they all give same UTC time?

+1 Excellent question considering the amount of wrong answers :-) — Aaron Digulla, Aug 07 '12 at 12:27
So time() call from machines with different timezones may not be the same considering inclusion of leap seconds and precision both of which are configurable/system-dependent. But for most of the system it will be the same. Is my conclusion right? — 0xc0de, Aug 10 '12 at 06:35
Also almost all the answers (atm) are answering my question partially, I'll choose the one which is more complete. — 0xc0de, Aug 10 '12 at 06:37

phihag · Accepted Answer · 2012-08-07T13:00:35.803

26

Yes, time.time() returns the number of seconds since an unspecified epoch. Note that on most systems, this does not include leap seconds, although it is possible to configure your system clock to include them. On cpython, time.time is implemented as a call to the C function time, which per §27.23.2.4.2 of the C standard does not have to use a specified epoch:

The time function determines the current calendar time. The encoding of the value is unspecified.

On virtually every OS (including Linux, Mac OSX, Windows, and all other Unixes), the epoch is 1970-1-1, 00:00 UTC, and on these systems time.time is timezone-independent.

edited Aug 07 '12 at 13:00

answered Aug 07 '12 at 12:22

phihag

278,196
72
453
469

3

time() returns "time() returns the time as the number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC)." as per the time(2) manual page. – Aaron Digulla Aug 07 '12 at 12:24
@AaronDigulla Oh, you're totally right. Fixed. Note that `time(2)` is in theory OS-specific. – phihag Aug 07 '12 at 12:27
It's the same for all Unix-based systems, so only Windows and MacOS < X could behave differently. – Aaron Digulla Aug 07 '12 at 12:36
3

@AaronDigulla It turns out time.time uses the same epoch on Windows as well. Only a small minority of systems actually returns the the time as the number of seconds since the Epoch - most leave out the leap seconds. From [`time(2)`](http://linux.die.net/man/2/time): `This value is not the same as the actual number of seconds between the time and the Epoch (...)`. – phihag Aug 07 '12 at 12:57

score 4 · Answer 2 · answered Aug 07 '12 at 12:23

The return value should be the same, since it's the offset in seconds to the UNIX Epoch.

That being said, if you convert it to a Date using different timezones, the values will, of course, differ.

If, from those Dates, you convert each of them to UTC, then the result has to be the same.

score 3 · Answer 3 · answered Aug 07 '12 at 12:22

3

time.time() returns the number of seconds since the UNIX epoch began at 0:00 UTC, Jan 1, 1970. Assuming the machines have their clocks set correctly, it returns the same value on every machine.

answered Aug 07 '12 at 12:22

Wooble

87,717
12
108
131

`gmtime()` works on `struct_time` while `time()` works on seconds. And the documentation says `gmtime()` is the same as `gmtime(time())` – Aaron Digulla Aug 07 '12 at 12:26
2

Yes, `gmtime` converts a number of seconds to the corresponding UTC struct_time. Not sure how that's relevant to the question. – Wooble Aug 07 '12 at 12:28
+1. "Assuming the machines have their clocks set correctly..." – Steven Rumbalski Aug 07 '12 at 12:37

score 3 · Answer 4 · edited May 23 '17 at 12:13

Per the documentation:

Return the time in seconds since the epoch as a floating point number. Note that even though the time is always returned as a floating point number, not all systems provide time with a better precision than 1 second. While this function normally returns non-decreasing values, it can return a lower value than a previous call if the system clock has been set back between the two calls.

Wikipedia says about "Unix epoch":

The Unix epoch is the time 00:00:00 UTC on 1 January 1970 (or 1970-01-01T00:00:00Z ISO 8601).

and it continues

There is a problem with this definition, in that UTC did not exist in its current form until 1972; this issue is discussed below. For brevity, the remainder of this section uses ISO 8601 date format, in which the Unix epoch is 1970-01-01T00:00:00Z.

Time and date is fun.

Little known fact: The time zone of Switzerland before 1894 was 34:08 (34 minutes and 8 seconds). After June 1894, it was updated to 29:44. (link)

@AaronDigulla: Your edit adds so much to this answer that it is no longer RobB's. If I were the author I would not appreciate such an extensive edit. It would have been better to write a long comment or a separate answer. — Steven Rumbalski, Aug 07 '12 at 12:43

score 1 · Answer 5 · answered Aug 07 '12 at 12:21

1

From the documentation:

Most of the functions defined in this module call platform C library functions with the same name. It may sometimes be helpful to consult the platform documentation, because the semantics of these functions varies among platforms.

http://docs.python.org/library/time.html?highlight=time.time#module-time

So the answer is: it depends.

answered Aug 07 '12 at 12:21

3

It depends on C's `time()` which says: "time() returns the time as the number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (**UTC**)." – Aaron Digulla Aug 07 '12 at 12:24

Aldian Fazrihady · Answer 6 · 2020-09-30T13:08:26.973

time.time() returns the same value, on any machine running time.time() simultaneously, even though those machines are using different timezones.

I have two machines, one is using UTC, the other one is using UTC+7.

I run this script on both machines almost simultaneously (the UTC one is about three seconds earlier):

import time
from datetime import datetime
import pytz

print("GENERATING TIMESTAMP:")
print("                                           time.time()", int(time.time()))
print("                            datetime.now().timestamp()", int(datetime.now().timestamp()))
print("datetime.utcnow().replace(tzinfo=pytz.UTC).timestamp()", int(datetime.utcnow().replace(tzinfo=pytz.UTC).timestamp()))
print("                         datetime.utcnow().timestamp()", int(datetime.utcnow().timestamp()))

ts = datetime.utcnow().replace(tzinfo=pytz.UTC).timestamp()

print("\nGENERATING DATETIME FROM TIMESTAMP ts =", ts)
print("                         datetime.fromtimestamp(ts)", datetime.fromtimestamp(ts))
print("            datetime.fromtimestamp(ts, tz=pytz.UTC)", datetime.fromtimestamp(ts, tz=pytz.UTC))
print("datetime.fromtimestamp(ts).replace(tzinfo=pytz.UTC)", datetime.fromtimestamp(ts).replace(tzinfo=pytz.UTC))

The UTC machine printed this:

GENERATING TIMESTAMP:
                                           time.time() 1601469475
                            datetime.now().timestamp() 1601469475
datetime.utcnow().replace(tzinfo=pytz.UTC).timestamp() 1601469475
                         datetime.utcnow().timestamp() 1601469475

GENERATING DATETIME FROM TIMESTAMP ts = 1601469475.713351
                         datetime.fromtimestamp(ts) 2020-09-30 12:37:55.713351
            datetime.fromtimestamp(ts, tz=pytz.UTC) 2020-09-30 12:37:55.713351+00:00
datetime.fromtimestamp(ts).replace(tzinfo=pytz.UTC) 2020-09-30 12:37:55.713351+00:00

The UTC+7 machine printed this:

GENERATING TIMESTAMP:
                                           time.time() 1601469478
                            datetime.now().timestamp() 1601469478
datetime.utcnow().replace(tzinfo=pytz.UTC).timestamp() 1601469478
                         datetime.utcnow().timestamp() 1601444278

GENERATING DATETIME FROM TIMESTAMP ts = 1601469478.637603
                         datetime.fromtimestamp(ts) 2020-09-30 19:37:58.637603
            datetime.fromtimestamp(ts, tz=pytz.UTC) 2020-09-30 12:37:58.637603+00:00
datetime.fromtimestamp(ts).replace(tzinfo=pytz.UTC) 2020-09-30 19:37:58.637603+00:00

You can see that time.time() is supposed to return the same value on any machine regardless of the timezone used by that machine.

Also, suppose time.time() has been called from places with different timezones, and converted to UTC datetimes on their machines, will they all give same UTC time?

Yes, the second line from the bottom of experiment result shows that.

I have a question. In the UTC+7, why does "datetime.utcnow().timestamp()" return the different value from the other? — Gatsby Lee, Feb 24 '23 at 04:00
Well. self-answered. The reason why `datetime.utcnow().timestamp()` returns `1601444278` is because datetime.utcnow() returns naive datetime obj. And, if datetime.timestamp() gets a naive datetime, it treats the value as local time. ( unexpected result ) — Gatsby Lee, Feb 24 '23 at 04:46

Is Python's time.time() timezone specific?

6 Answers6

Linked