BUG: timezone comparisions are inconsistent, manifesting in bugs in .concat #19281
Conversation
|
cc @jschendel |
| timezones. For example | ||
| `<DstTzInfo 'Europe/Paris' LMT+0:09:00 STD>` and | ||
| `<DstTzInfo 'Europe/Paris' CET+1:00:00 STD>` are essentially same | ||
| timezones but aren't evaluted such, but the string representation |
There was a problem hiding this comment.
When you say "aren't evaluated as such" are you talking about ==? i.e. start == end is False, but tz_compare(start, end) is True?
There was a problem hiding this comment.
@TomAugspurger Yes, the reason for this is that pytz generates a separate tzinfo object for each unique offset/tzname combination, and that is what is attached when you call .localize or .normalize. These time zones don't compare equal to one another.
It might be worth noting that this function exists only to add a notion of equality to pytz-style zones that is compatible with the notion of equality expected of tzinfo subclasses.
There was a problem hiding this comment.
Another thing that might be worth noting is that, as currently written (and probably it would be out of scope to fix this), this will not disambiguate zones that are actually links to other zones.
See the backward file, US/Eastern is a link to America/New_York, for example, but that information is not accessible either from pytz or from the zoneinfo files, as far as I know. Even though pytz.timezone(US/Eastern) and pytz.timezone(America/New_York) always generate the same exact rules, they will be treated as different zones for purposes of tz_compare (which also means concat will merge them and convert to UTC).
Codecov Report
@@ Coverage Diff @@
## master #19281 +/- ##
=======================================
Coverage 91.56% 91.56%
=======================================
Files 148 148
Lines 48874 48874
=======================================
Hits 44751 44751
Misses 4123 4123
Continue to review full report at Codecov.
|
closes #18523
superseded #18596