Skip to content

Compare of datetime.time ignores tz microseconds #99772

Closed

Description

@blenq

Bug report

Compare operations of datetime.time values ignore microseconds in timezone offsets. These operations might return wrong results in the rare event that timezone offsets contain microseconds.

Show case:

>>> from datetime import time, timedelta, timezone
>>> time(13, 12, tzinfo=timezone(timedelta(microseconds=2))) == time(13, 12, tzinfo=timezone(timedelta()))
True
>>> time(13, 12, tzinfo=timezone(timedelta(seconds=2))) == time(13, 12, tzinfo=timezone(timedelta()))
False

Both statements should return False.

Your environment

  • CPython versions tested on:
    Python 3.7.15, 3.10.8, 3.11.0, 3.12.0a2 locally compiled
    Python 3.8.10, 3.9.5 from Ubuntu repo

  • Operating system and architecture:
    Ubuntu 20.04.5 (amd64)

Patch is on the way

Linked PRs

Activity

  1. added
    type-bugAn unexpected behavior, bug, or error
    on Nov 25, 2022
  2. added 4 commits that reference this issue on Nov 25, 2022
  3. brandonschabell commented on Nov 27, 2022

    @brandonschabell
    Contributor

    What's the use case for this? I don't believe there are any timezones that aren't perfectly defined using an integer number of minutes offset from UTC.

  4. blenq commented on Nov 27, 2022

    @blenq
    Author

    What's the use case for this? I don't believe there are any timezones that aren't perfectly defined using an integer number of minutes offset from UTC.

    You are right if you only take current timezones into consideration. On the other hand, historic timezones exist with seconds and even fractional seconds in the UTC offset. According to IANA itself:

    https://github.com/eggert/tz/blob/eb4b696c17b0366ab5a0b4c77b527613fef295d8/europe#L2031
    https://github.com/eggert/tz/blob/eb4b696c17b0366ab5a0b4c77b527613fef295d8/europe#L299
    https://github.com/eggert/tz/blob/eb4b696c17b0366ab5a0b4c77b527613fef295d8/europe#L1272
    https://github.com/eggert/tz/blob/eb4b696c17b0366ab5a0b4c77b527613fef295d8/europe#L3111
    https://github.com/eggert/tz/blob/eb4b696c17b0366ab5a0b4c77b527613fef295d8/europe#L2159
    https://github.com/eggert/tz/blob/eb4b696c17b0366ab5a0b4c77b527613fef295d8/europe#L2813

    The iana tzdata rounds these to whole seconds, because the tzdata format does not support fractional seconds, but it is perfectly possible to use another zoneinfo library which provides these fractional second offsets, or fabricate them yourself, like I did above. I do agree that these are obscure and almost theoretical edge cases, and that you probably won't be bitten by it, unlike me.

    Besides the actual existence of such exotic timezones, I think it should be fixed for the sake of completeness as well. Other solutions are possible of course. For example, fractional seconds can be forbidden in timezone offsets. Prior to 3.7 this was the case, even for whole seconds; minimal resolution was whole minutes in 3.6. I chose to follow the "if it is supported, support it" approach, and fix the discrepancy.

  5. added 4 commits that reference this issue on Nov 27, 2022
  6. added
    stdlibStandard Library Python modules in the Lib/ directory
    on Nov 26, 2023
  7. added a commit that references this issue on Sep 5, 2026
  8. added a commit that references this issue on Sep 7, 2026
  9. added a commit that references this issue on Sep 12, 2026
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

    extension-modulesC modules in the Modules dirstdlibStandard 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