Compare of datetime.time ignores tz microseconds

[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

• gh-99772: Do not ignore utc offset microseconds #99774

[brandonschabell]

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.

[blenq]

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.