Skip to content

Subsequent datetime.now() calls return the same datetime #124832

Closed

Description

@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

Activity

  1. vstinner commented on Oct 1, 2024

    @vstinner
    Member

    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.

  2. vstinner commented on Oct 1, 2024

    @vstinner
    Member

    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?

  3. spacemanspiff2007 commented on Oct 1, 2024

    @spacemanspiff2007
    ContributorAuthor

    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.

  4. added a commit that references this issue on Oct 8, 2024
  5. added 2 commits that reference this issue on Oct 8, 2024
  6. added 2 commits that reference this issue on Oct 8, 2024
  7. added a commit that references this issue on Oct 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    type-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions