GeezerVison is showing github.com — Subsequent datetime.now() calls return the same datetime · Issue #124832 · python/cpython
Subsequent datetime.now() calls return the same datetime #124832DescriptionBug 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
Activityvstinner commented on Oct 1, 2024
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. Reacted by Gilles Marchand vstinner commented on Oct 1, 2024
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 commented on Oct 1, 2024 ContributorAuthor More actions 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. added a commit that references this issue on Oct 8, 2024gh-124832: Add a note to indicate that `datetime.now` may return the …
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|