为什么Python的datetime.utcnow()总是返回相同的微秒值?

dth*_*hor 5 python datetime python-3.x python-datetime python-3.4

我正在玩Python的datetime.datetime.utcnow()方法,我注意到微秒值始终是相同的.

>>> import datetime
>>> datetime.datetime.utcnow()
datetime.datetime(2015, 11, 16, 23, 20, 46, 42286)
>>> datetime.datetime.utcnow()
datetime.datetime(2015, 11, 16, 23, 20, 55, 505286)
>>> datetime.datetime.utcnow()
datetime.datetime(2015, 11, 16, 23, 21, 1, 552286)
Run Code Online (Sandbox Code Playgroud)

注意微秒值是如何总是286.为什么会这样?我该怎么做才能解决这个问题?

更多信息:time.time()也总是有286us.毫秒值很好.我认为这实际上是根本原因,因为我相信datetime.datetime.utcnow()会调用time.time().


这是一个简短的脚本,表明它不仅仅是运气:

import datetime, random, time

for wait_time in [random.random() for _ in range(10)]:
    time.sleep(wait_time)
    print("Waited {}, result {}".format(wait_time, datetime.datetime.utcnow()))
Run Code Online (Sandbox Code Playgroud)

结果:

Waited 0.6074311218736113, result 2015-11-16 23:35:24.603286
Waited 0.960317012489652, result 2015-11-16 23:35:25.563286
Waited 0.13555474339177553, result 2015-11-16 23:35:25.698286
Waited 0.6179213307667111, result 2015-11-16 23:35:26.315286
Waited 0.2872301475401443, result 2015-11-16 23:35:26.602286
Waited 0.42578113509089066, result 2015-11-16 23:35:27.027286
Waited 0.647233264729425, result 2015-11-16 23:35:27.674286
Waited 0.38930513172405146, result 2015-11-16 23:35:28.063286
Waited 0.6500370260649043, result 2015-11-16 23:35:28.713286
Waited 0.9807308512288959, result 2015-11-16 23:35:29.693286
Run Code Online (Sandbox Code Playgroud)

谢谢,


系统信息:

  • 在win32上的Python 3.4.3(v3.4.3:9b73f1c3e601,2015年2月24日,22:44:40)[MSC v.1600 64位(AMD64)]
  • Windows 7专业版,Service Pack 1. 64位.
  • 英特尔酷睿i5-2400 @ 3.10GHz

time.get_clock_info()的结果

Name          Adjustable  Implementation             Monotonic  Resolution (seconds)
============  ==========  =========================  =========  ====================
clock         False       QueryPerformanceCounter()  True       3.3106597e-07
monotomic     False       GetTickCount64()           True       0.015600099999
perf_counter  False       QueryPerformanceCounter()  True       3.3106597e-07
process_time  False       GetProcessTime()           True       1e-7
time          True        GetSystemTimeAsFileTime()  False      0.015600099999
Run Code Online (Sandbox Code Playgroud)

最终编辑:

所以,我第二天早上回到这里(电脑整晚都待在这里),我再次启动了python翻译,现在一切都很好!

什么鬼,伙计?

>>> datetime.datetime.utcnow()
datetime.datetime(2015, 11, 17, 17, 19, 17, 626982)
>>> datetime.datetime.utcnow()
datetime.datetime(2015, 11, 17, 17, 19, 18, 234043)
>>> datetime.datetime.utcnow()
datetime.datetime(2015, 11, 17, 17, 19, 19, 106130)
>>> datetime.datetime.utcnow()
datetime.datetime(2015, 11, 17, 17, 20, 7, 707990)
Run Code Online (Sandbox Code Playgroud)

我仍然感兴趣的是,为什么这样做/可能首先发生,所以如果有人有任何额外的信息,那将是伟大的.可悲的是,我不知道我是否能够复制它......

Kar*_*ath 2

免责声明:这不是答案。


我看到了完全不同的微秒,所以我做了这个实验:

ms = 0
for _ in range(10000):
    ms_ = datetime.datetime.utcnow().microsecond % 10000
    if ms != ms_:
        diff = (ms_ - ms) % 1000
        ms = ms_
        print ms, diff
Run Code Online (Sandbox Code Playgroud)

它显示了微秒的变化(我只是多显示了一位数字,因此增加是可见的):

8007 7    # garbage
8984 977
9960 976
937 977
1914 977
2890 976
3867 977
4843 976
5820 977
6796 976
7773 977
8750 977
9726 976
703 977
1679 976
2656 977
3632 976
4609 977
5585 976
Run Code Online (Sandbox Code Playgroud)

正如您所看到的,在我的 Windows 机器上,增量非常一致。它只是不是 1000,就像在 OP 的机器上一样,所以这就是为什么我(我们?)观察到不同的微秒。增量可能与某个系统时钟同步,我猜,在OP的机器上每毫秒重新触发一次?

很想听听其他人的一些观察。欢迎发表评论。

注意:这是 T4500,运行频率为 2.30GHz。