Question: I see a difference in the datetime.now() function in Windows Python 3.11 vs WSL Python 3.10 and Linux Python 3.10. On Windows, I get duplicate entries. On WSL and Linux, I don't. I am converting a test system from primarily being used with Python in WSL to using Python in Windows natively and hit a kind of weird issue. At one place the previous author was recording the datetime.now() at the outset of the script, then checking its delta later to see if it was still the same (I'm legit not sure why, but this is what was going on). This suddenly broke with Python in Windows. After some digging, it seems that it's because there is literally no delta in the two datetime.now() calls most of the time. I tried it with WSL and it still worked. Here's an example of what I'm talking about in germ: from datetime import datetime as dt for i in range(0,10): print(f"date and time is: {dt.now()}")  With Windows, this is what it prints out: date and time is: 2024-02-26 17:09:39.393765 date and time is: 2024-02-26 17:09:39.393765 date and time is: 2024-02-26 17:09:39.408956 date and time is: 2024-02-26 17:09:39.408956 date and time is: 2024-02-26 17:09:39.408956 date and time is: 2024-02-26 17:09:39.409962 date and time is: 2024-02-26 17:09:39.409962 date and time is: 2024-02-26 17:09:39.409962 date and time is: 2024-02-26 17:09:39.409962 date and time is: 2024-02-26 17:09:39.410971  As you can see, multiple entries are identical. Same system and code with WSL: date and time is: 2024-02-26 17:10:58.658753 date and time is: 2024-02-26 17:10:58.658802 date and time is: 2024-02-26 17:10:58.658828 date and time is: 2024-02-26 17:10:58.658837 date and time is: 2024-02-26 17:10:58.658857 date and time is: 2024-02-26 17:10:58.658880 date and time is: 2024-02-26 17:10:58.658888 date and time is: 2024-02-26 17:10:58.658892 date and time is: 2024-02-26 17:10:58.658911 date and time is: 2024-02-26 17:10:58.658935  No duplicates. My original assumption was that this was because of the overhead of WSL being a VM, but I'm not really sure. I just found it odd and couldn't really find any help with it online as it seems like usually the reason people run into datetime.now() "not updating" is because they're assigning the output to a variable and not rerunning it, but I am running it again each time. I was curious, so I just ran it again on a Linux box I have set up (Ubuntu 22.04), and it never saw any duplicates either. date and time is: 2024-02-27 09:38:16.767813 date and time is: 2024-02-27 09:38:16.767853 date and time is: 2024-02-27 09:38:16.767860 date and time is: 2024-02-27 09:38:16.767864 date and time is: 2024-02-27 09:38:16.767869 date and time is: 2024-02-27 09:38:16.767873 date and time is: 2024-02-27 09:38:16.767878 date and time is: 2024-02-27 09:38:16.767882 date and time is: 2024-02-27 09:38:16.767889 date and time is: 2024-02-27 09:38:16.767894  I checked the Python versions in each and do see a difference: Windows: Python 3.11.8 WSL: Python 3.10.12 Ubuntu: Python 3.10.12 The CPU's are different, too, if that matters in this case: Windows: i7-8700 CPU @ 3.20GHz, 3192 Mhz, 6 Core(s), 12 Logical Processor(s) Linux: lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address sizes: 39 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Vendor ID: GenuineIntel Model name: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz CPU family: 6 Model: 94 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 Stepping: 3 CPU max MHz: 3400.0000 CPU min MHz: 800.0000 It's easy to get the code I was working with to work with Windows' Python by adding a time.sleep(0.000001), and I'm not sure if the offending code is even needed, but I'm just curious why this is happening and wondered if anyone could shed any light on it. Thanks!

Answer: As Python uses underlying operating system features, some of its behaviors will differ depending on what OS fuels your runtime environment. And while your test is bit flawed because you use different Python versions, unifying these would most likely yield to similar results. Windows has historically had issues with time granularity, where the clock update frequency is not as high as on some Linux configurations. The precision of time measurements and the resolution of system time updates can significantly vary, leading to differences in how frequently datetime.now() returns a new value. The addition of time.sleep(0.000001) in your script likely forces the Python interpreter to yield execution long enough for the system clock to update, thus avoiding duplicates. This workaround is generally acceptable but should be used judiciously, understanding that it introduces a small overhead to each loop iteration which might be not really needed if such detailed time granularity is not really necessary.