You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Compare of datetime.time ignores tz microseconds #99772
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.
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.
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:
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.
Activity
pythongh-99772: Do not ignore utc offset microseconds
pythongh-99772: Do not ignore utc offset microseconds
pythongh-99772: Do not ignore utc offset microseconds
pythongh-99772: Fix for Windows
brandonschabell commentedon Nov 27, 2022
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 commentedon Nov 27, 2022
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.
pythongh-99772: Implement suggestions
pythongh-99772: Do not ignore utc offset microseconds
pythongh-99772: Fix for Windows
pythongh-99772: Implement suggestions
pythongh-99772: Address review comments
gh-99772: Fix datetime.time comparison and hashing for sub-minute UTC…
pythongh-99772: Fix datetime.time comparison and hashing for sub-minu…