Why does Python datetime.utcnow () always return the same value for microseconds?

Question

I play with the Python method datetime.datetime.utcnow (), and I notice that the value of the microsecond is always the same.

>>> 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) 

Note that the microsecond value is always 286. Why? And what can I do to fix this?

A bit more info: time.time() also always has 286us. The values ​​in milliseconds are beautiful. I think this is actually the root cause, since I believe datetime.datetime.utcnow () calls time.time ().

---

Here's a short script that shows that this is not just luck:

 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())) 

Result:

 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 

Thanks,

---

System Information:

• Python 3.4.3 (v3.4.3: 9b73f1c3e601, February 24, 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
• Windows 7 Professional, Service Pack 1. 64-bit.
• Intel Core i5-2400 @ 3.10GHz

Results 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 

---

Final Edit:

So, I will come back to this the next morning (the computer stayed all night), and I started the python interpreter again, and now everything is fine!

What the hell is a man?

 >>> 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) 

I'm still wondering why this would / could happen in the first place, so if anyone has any additional information, that would be great. Unfortunately, I do not know if I can reproduce it ...

Answer 1

Disclaimer: This is not an answer.

---

I saw completely different microseconds, so I did this experiment:

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

It shows the change in microseconds (I just show one more figure so that the increase is visible):

 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 

As you can see, on my Windows machine the delta is quite consistent. This is not 1000, as on the OP machine, so I (we?) Observe different microseconds. Probably the delta is in sync with some system clocks, which, I think, on restarting the OP machine in every millisecond?

I would like to hear some observations from others. Feel free to comment.

Note: this is a T4500 operating at 2.30 GHz.

Answer 2

There, an old joke about two people at the Natural History Museum is interested in how many fossil dinosaurs remain. The guard overhears them and says: "Oh, it's five hundred million and seven years." One of the people says: "This is an amazing number, how was it determined?" The guard says: "Well, I was told that during my orientation it was five hundred million years, and that was seven years ago."

This is the result of combining two times with different levels of accuracy. Let's say I start the watch at 12:03:06, and the watch has only a minute resolution. If I add time to the clock before the start, I will get a series of times, for example, 12:03:06, 12:04:06, 12:05:06, etc.

Windows adds time from a monotonous clock with a resolution in milliseconds and an arbitrary start time to the moment when this clock is considered zero with a resolution in microseconds.

A common technique is simply to round the time to the resolution you rely on, which, of course, should not be higher than the resolution guaranteed by the watch. I believe the guaranteed resolution for this watch is 10 milliseconds.