当运行python的计算机的时钟(Windows或Linux)时会发生什么
自动更改并调用time.time()?
我已经读过,当手动将时钟更改为某个值时,time.time()的值会更小。
-
试试吧,看看会发生什么。
-
更改Windows下的时钟是否会更改UTC值或我的区域设置时间值? 编辑:Mhh猜测改变时区会做到吗?
-
相关:python的time.time()方法如何工作?
-
更改时钟(通过控制面板,命令行或OS功能)通常将本地时间作为输入,但最终必须将其转换为UTC,然后再通过Windows的SetSystemTime调用进行设置。 操作系统仅在内部跟踪UTC。 本地时间转换用于输入,显示和写入BIOS等。请注意,更改时区不会更改正在跟踪的UTC值。 它仅更改转换期间使用的区域。
time.time() docs说:
Return the time in seconds since the epoch as a floating point number.
这里提到的特定时代是Unix时代,即UTC时间1970年1月1日午夜。
由于它始终基于UTC,因此不会更改计算机的时区,也不会影响计算机的时区进入或退出夏令时。
尽管该函数确实依赖于底层实现来提供值,但这些实现始终以UTC的形式返回值 - 无论操作系统如何。
特别是在Windows上,它最终调用GetSystemTimeAsFileTime OS函数,该函数以UTC的形式返回其值。它不受时区选择或时区内DST更改的影响。
-
它不是那么简单。 UTC时间和OS认为的UTC时间可能不同。
-
当然,如果你在谈论时钟同步,以及它的同步程度如何。但这不是我们在这里谈论的......
-
我正在谈论任何可能的差异。让我们假设在更改本地时区之前,时钟是精确的:您是否声称可以保留UTC和本地时间的先前值,无论您如何更改本地时区设置?例如,假设您在保持本地时间相同的情况下更改了UTC偏移量:您的声明是UTC时间也保持不变,导致系统不一致,因为如果旧的和新的UTC偏移量不同(local = utc + offset:如果偏移已经改变,则不能保留local和utc)。
-
不,我没有声称你所描述的。我只是说如果时钟相对于UTC是精确的,那么在改变时区后,时钟仍然相对于UTC是精确的。现在,本地时间在Windows任务栏上显示的方式与之前的方式不同,但不修改基础UTC值。
-
除非你声称在改变当地时区时不可能保留当地时间(我不关心如何可能);我的观点 - 即使您需要的是在保留当地时间的同时更改本地时区,time.time()值也可能会发生变化。
-
@ J.F.Sebastian - 是的,这是完全正确的。在改变当地时区时,不可能保留当地时间。您可以更改时区,也可以更改时间,但不能同时进行。我只声称时区更改不会影响time.time()。我并不是说改变时间不会影响事情。
-
在最低的公共API级别,Windows调用是SetSystemTime和SetDynamicTimeZoneInformation。前者只需要UTC时间,而后者根本不需要时间。 (内部也没有什么不同。)
-
我不怀疑它可能需要多个步骤。想象一下你的硬件时钟被解释为本地时间(Windows经常这样做),本地时间本身是正确的,但你注意到UTC时间错误,因为本地时区设置不正确:你修复了时区,当地时间保持不变相同(正确)的值,utc时间的变化。
引用time.time的文档,
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.
调整系统时钟值的因素取决于平台。但是,根据评论,这不应包括基于DST的更改,因为Python支持的所有操作系统都提供系统调用来检索UTC中的当前时间(并且DST仅影响本地时间与UTC的关系)。
如果这不是一个足够好的保证,你可能更喜欢time.montonic,这保证永远不会倒退 - 但是,请注意它附带了这个警告(并决定这是否对你的用例很重要):
The reference point of the returned value is undefined, so that only
the difference between the results of consecutive calls is valid.
-
双启动时钟时间关闭表示Linux和Windows都可以使用utc和本地时间选项。 Windows更有可能将硬件时钟设置为当地时间。如果仅更改DST设置,则不清楚GetSystemTimeAsFileTime()(由time.time()使用)返回(如果可能:相同的本地时间,不同的DST设置意味着不同的utc偏移,因此可能有不同的utc时间 - 否则系统会不一致)。
-
Windows系统时间也以UTC表示。仅将BIOS写为本地时间。启动时会自动进行转换,并且每当本地时间发生更改时(对于DST,NTP或用户修改),但UTC是操作系统跟踪的内容,并且它不会因DST或其他时区更改而更改。请注意,GetSystemTimeAsFileTime的文档明确说明返回值是UTC。
-
@MattJohnson:(1)我被msdn中的谎言咬了很多次,直到在相关系统上测试相应的声明,我才不相信它(2)值(类似于POSIX时间戳)不在任何时区虽然GetSystemTimeAsFileTime()(自1600年以来的100s纳秒)可以轻松转换为UTC。我不会猜测如果更改DST设置会发生什么(不是转换,而是设置,例如,在保持相同的本地时间的同时设置不同的本地时区)
-
更改时区与更改时间无关。更改时区时,通过将系统时间转换为新时区自动更新本地时间。因此,在仅更改时区时,不能保持相同的本地时间(除非这两个时区恰好在当前时间对齐)。换句话说,如果我的时钟是当地时间的7:00,并且我将时区从太平洋更改为东部(有效DST),我的本地时钟现在将读取10:00,因为基础UTC时间为14: 00没有改变(正常滴答前进除外)。
-
@MattJohnson:我明确表示当地时间得以保留。
-
@ J.F.Sebastian - 我知道。这就是为什么我试图告诉你,这不是它在Windows上的运作方式。当地时间不是保留的。一个人独立设置时间和时区。要保留当地时间,您必须同时更改时区,然后单独调整时钟。
-
@MattJohnson:这就是我的观点:即使您只需要更改本地时区设置;您最终可能会更改time.time()结果。
-
让我们在聊天中继续讨论。
time.time()返回底层库返回的值。 Python使用time(..)或gettimeofday(.., nullptr)(取决于系统上可用的内容)。
https://github.com/python-git/python/blob/master/Modules/timemodule.c#L874
在这两种情况下都返回UTC。例如:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html
The time() function shall return the value of time in seconds since the Epoch
在对Matt的有效评论之后,我必须添加epoch的定义,该定义明确指出time返回UTC时间。
Epoch:
Historically, the origin of UNIX system time was referred to as
"00:00:00 GMT, January 1, 1970". Greenwich Mean Time is actually not a
term acknowledged by the international standards community; therefore,
this term,"Epoch", is used to abbreviate the reference to the actual
standard, Coordinated Universal Time.
为了证明这个时代是相同的检查:
1 2 3 4 5
| 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对于localtime设置为true,对于gmtime设置为false(表示自纪元以来的时间)。
编辑:你在哪里读到价值会更小?
-
在该非常相同的参考文献中,这里术语"Epoch"是关于UTC定义的。所以它不依赖于平台。
-
在所有现代用途中,GMT与UTC的价值相当。它们只是在语义上不同,而不是在价值上。
-
确实如此,我完成了答案。