Subsequent datetime.now() calls return the same datetime

[spacemanspiff2007]

Bug report

Bug description:

Subsequent datetime.now() may return the same moment in time.

from datetime import datetime, UTC

now1 = datetime.now(UTC)
for i in range(10_000):
    a = i
now2 = datetime.now(UTC)

assert now1 < now2

    assert now1 < now2
           ^^^^^^^^^^^
AssertionError

This does seem to work as expected:

from time import sleep
from datetime import datetime, UTC

now1 = datetime.now(UTC)
sleep(0.000_000_001)
now2 = datetime.now(UTC)

assert now1 < now2

I'm not sure if this is a bug, but at least it's a documentation issue.
There's nothing in the docs explicitly indicating this behavior.

CPython versions tested on:

3.12

Operating systems tested on:

Windows

Linked PRs

• gh-124832: Add a note to indicate that datetime.now may return the same instant #124834
• [3.13] gh-124832: Add a note to indicate that datetime.now may return the same instant (GH-124834) #125145
• [3.12] gh-124832: Add a note to indicate that datetime.now may return the same instant (GH-124834) #125146

[vstinner]

CPython versions tested on: 3.12
Operating systems tested on: Windows

Test with Python 3.13, it got better clocks: https://docs.python.org/dev/whatsnew/3.13.html#time

On Windows, time() now uses the GetSystemTimePreciseAsFileTime() clock for a resolution of 1 microsecond, instead of the GetSystemTimeAsFileTime() clock which has a resolution of 15.6 milliseconds. (Contributed by Victor Stinner in gh-63207.)

On Python 3.12, it's more likely that two consecutive calls to datetime.now() gives the same microseconds.

[vstinner]

I'm not sure if this is a bug, but at least it's a documentation issue.

It's not a bug.

There's nothing in the docs explicitly indicating this behavior.

What do you expect in the doc?

[spacemanspiff2007]

I understand and suspected as much.

What do you expect in the doc?

A warning that due to the clock resolution it's possible that two datetime.now() calls can return the same time even though a "substantial" amount of time has passed.

I had some tests failing which check that a datetime value which was updated was in the future.
That failed and I could not figure out why. I supplied UTC as tz because the docs mention it might increase precision but with no success.
A warning or hint would have been nice which I tried to add in the PR.