我正在玩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)
注意微秒值是如何总是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()))
结果:
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
谢谢,
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
所以,第二天早上我回到这里(电脑整夜待在那里)我再次启动了蟒蛇翻译,现在一切都很好!
哎呀,伙计?
>>> 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)
我仍然对为什么这样做/可能首先发生的事情感兴趣,所以如果有人有任何额外的信息会很棒。可悲的是,我不知道我是否能够复制它......
答案 0 :(得分: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
它显示了微秒的变化(我只是显示了一个数字,因此可以看到增加):
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
正如您所看到的,在我的Windows机器上,delta非常一致。它只是不是1000,就像OP的机器一样,这就是为什么我(我们?)观察不同的微秒。 delta可能与某些系统时钟同步,我想,这可能是OP的机器在每个毫秒内重新启动的?
很想听别人的一些观察。随意评论。
注意:这是一台运行频率为2.30GHz的T4500。
答案 1 :(得分:2)
在自然历史博物馆里有一个关于两个人的老笑话,想知道恐龙化石有多久了。一名警卫无意中听到他们说,"哦,它已经五亿七十岁了。其中一个人说,"这是一个惊人的数字,它是如何确定的?"警卫说,"嗯,有人告诉我,在我的导演期间它已经有五亿年了,而那是七年前的事了。"
这是将不同精度水平加在一起两次的结果。假设我在12:03:06开始计时,那个时钟只有很小的分辨率。如果我把时钟加到开始时间,我会得到一系列的时间,比如12:03:06,12:04:06,12:05:06,等等。
Windows正在将具有毫秒分辨率和任意开始时间的单调时钟添加到该时钟以微秒分辨率读取零的时间。
一种常见的技术就是将时间缩短到您所依赖的分辨率,当然这不得高于时钟的保证分辨率。我相信这个时钟的保证分辨率是10毫秒。