Python的time.time()函数返回的是底层库返回的值。Python使用time(..)或gettimeofday(.., nullptr)（取决于系统上可用的内容）。

无论哪种情况，都返回的是UTC时间。例如：

http://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html

time()函数应返回自纪元以来的秒数

根据Matt的一个有效评论，我必须添加对epoch的定义，它清楚地说明time返回的是UTC时间。

纪元：

历史上，UNIX系统时间的起点被称为“00:00:00 GMT，1970年1月1日”。格林尼治标准时间实际上不是国际标准委员会承认的一个术语；因此，这个术语“纪元”用于缩写对实际标准的引用，即协调世界时。

为了证明纪元是相同的，请检查以下内容：

import time
a = time.gmtime(secs=0)
# time.struct_time(tm_year=2015, tm_mon=9, tm_mday=9, tm_hour=1, tm_min=3, tm_sec=28, tm_wday=2, tm_yday=252, tm_isdst=0)
b = time.localtime(secs=0)
# time.struct_time(tm_year=2015, tm_mon=9, tm_mday=9, tm_hour=3, tm_min=1, tm_sec=28, tm_wday=2, tm_yday=252, tm_isdst=1)

如果参数secs为0，这两个函数都使用time.time()返回的值。在我的情况下，对于本地时间，tm_isdst被设置为true，而对于UTC时间（自纪元以来的时间），tm_isdst被设置为false。

编辑：你在哪里读到值会更小？

在同一个参考文献中，这里定义了“纪元”与UTC相关。因此，它不是依赖于平台的。

在现代用法中，GMT和UTC的值是等效的。它们只在语义上有所区别，而不是在值上有所区别。

这确实是真的，我完善了我的答案。

Python中的time.time()函数返回的值通常是递增的，但如果在两次调用之间系统时钟被设置回去了，它可以返回一个较低的值。

系统时钟的调整是依赖于平台的。但是，根据评论，这个调整不应该包括基于夏令时的变化，因为Python支持的所有操作系统都提供了用于检索当前UTC时间的系统调用（夏令时只影响本地时间与UTC时间的关系）。

如果这不能提供足够的保证，可以使用time.monotonic()函数，它保证不会倒退。然而，需要注意的是，它的参考点是不确定的，所以只有连续调用的结果之间的差值是有效的。

Linux和Windows都可以使用UTC和本地时间选项。更有可能的是，Windows将硬件时钟设置为本地时间。如果只改变了夏令时设置（如果可能的话：相同的本地时间，不同的夏令时设置意味着不同的UTC偏移，因此可能是不同的UTC时间），那么不清楚GetSystemTimeAsFileTime()（被time.time()使用）会返回什么结果（系统可能会不一致）。

Windows系统时间也是以UTC为单位的。只有BIOS是按本地时间写入的。翻译发生在启动时自动进行，以及每当本地时间发生变化（用于夏令时、NTP或用户修改），但操作系统跟踪的是UTC时间，它不会因为夏令时或其他时区变化而改变。需要注意的是，GetSystemTimeAsFileTime的文档清楚地说明返回值是UTC时间。

更改时区与更改时间是相互独立的。当您更改时区时，本地时间会通过将系统时间转换为新时区自动更新。因此，如果只更改时区而保持相同的本地时间是不可能的（除非这两个时区恰好对当前时间进行了对齐）。换句话说，如果我的时钟显示的是当地时间7:00，并且我将时区从太平洋时区更改为东部时区（夏令时生效），那么我的时钟现在将显示为10:00，因为底层的UTC时间14:00并没有改变（除了正常的时间向前推移）。

我们可以在聊天中继续讨论这个问题。

Python的time.time()函数返回的是从epoch（1970年1月1日UTC）到当前时间的秒数。这个函数的返回值始终基于UTC，不会受到计算机时区的改变以及夏令时的影响。尽管函数的实现依赖于底层操作系统提供的值，但这些实现都是以UTC为基准返回值的，不受操作系统的影响。

但实际情况可能并不那么简单，UTC时间和操作系统认为的UTC时间可能会有所不同。如果我们谈论的是时钟的同步性以及它的精确程度，那么它们可能会有差异。但这并不是我们在这里讨论的问题。

我们讨论的是任何原因可能导致的差异。假设在本地时区发生变化之前，时钟是精确的：你是否声称无论如何改变本地时区设置，你都可以保留以前的UTC和本地时间的值？例如，想象一下在保持本地时间不变的情况下改变了UTC偏移量：你声称UTC时间也保持不变，这会导致系统不一致，因为如果旧的和新的UTC偏移量不同（本地时间= UTC时间+偏移量），无法同时保留本地时间和UTC时间。

不，我并没有声称你描述的那样。我只是简单地说，如果时钟相对于UTC是精确的，那么在改变时区后，时钟仍然相对于UTC是精确的。Windows任务栏上的本地时间可能与之前显示的不同，但底层的UTC值不会被修改。

除非你声称在改变本地时区的同时保留本地时间是不可能的（我不在乎如何，只要可能就行）；我的观点是正确的——即使你只需要改变本地时区而保留本地时间，time.time()的值也可能会改变。

是的，这完全正确。在改变本地时区的同时保留本地时间是不可能的。你可以改变时区，或者改变时间，但不能同时进行。我只是声称时区的改变不会影响time.time()。我并没有声称改变时间不会产生影响。

在最低级别的公共API层面，Windows的调用是SetSystemTime和SetDynamicTimeZoneInformation。前者只接受以UTC为基准的时间，而后者根本不接受时间。（在内部也没有区别。）

我不否认可能需要多个步骤。想象一下，你的硬件时钟被解释为本地时间（Windows经常这样做），本地时间本身是正确的，但你注意到UTC时间是错误的，因为本地时区设置不正确：你修复了时区，本地时间保持不变（正确的值），UTC时间发生了变化。