Skip to content

Python threading.Event().wait() depends on the system time #91394

Closed

Description

@AleksandrAQ
BPO 47238
Nosy @AleksandrAQ
Files
  • reproduction.py: You need root privileges to change the system time.
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = None
    created_at = <Date 2022-04-06.10:19:09.231>
    labels = ['3.8', 'type-bug', 'library']
    title = 'Python threading.Event().wait() depends on the system time'
    updated_at = <Date 2022-04-06.10:19:09.231>
    user = 'https://github.com/AleksandrAQ'

    bugs.python.org fields:

    activity = <Date 2022-04-06.10:19:09.231>
    actor = 'AleksandrAQ'
    assignee = 'none'
    closed = False
    closed_date = None
    closer = None
    components = ['Library (Lib)']
    creation = <Date 2022-04-06.10:19:09.231>
    creator = 'AleksandrAQ'
    dependencies = []
    files = ['50725']
    hgrepos = []
    issue_num = 47238
    keywords = []
    message_count = 1.0
    messages = ['416851']
    nosy_count = 1.0
    nosy_names = ['AleksandrAQ']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = None
    status = 'open'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue47238'
    versions = ['Python 3.8']

    Activity

    1. AleksandrAQ commented on Apr 6, 2022

      AleksandrAQmannequin
      MannequinAuthor

      This happens on Ubuntu on Python versions 3.8.5 and 3.10.4

      I have two threads that can change the system time to a day ago.
      If the change in the system time for a day occurs at the time of wait, then I hang for one day plus the waiting time.

      I thought Event.wait() uses a monotonous clock, but this behavior points to an absolute clock.

      Are there any solutions?

    2. added
      stdlibStandard Library Python modules in the Lib/ directory
      type-bugAn unexpected behavior, bug, or error
      on Apr 6, 2022
    3. transferred this issue fromon Apr 10, 2022
    4. duaneg commented on Apr 19, 2025

      @duaneg
      Contributor

      I cannot reproduce this on the current HEAD, and looking through the logs I believe it was fixed by gh-28662 by @vstinner and released in v3.11.0. I think this issue can be closed as fixed.

    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

      3.8 (EOL)end of lifestdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

      Projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions