PERF: datetime index getters functions are 10 times slower with ZoneInfo vs pytz timezone

[kjmin622]

• closes PERF: datetime index getters functions are 10 times slower with ZoneInfo vs pytz timezone #64363, closes Potential performance regression with "CLN: enforce deprecation of frequencies deprecated for offsets" #58962 (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.
• I have reviewed and followed all the contribution guidelines
• If I used AI to develop this pull request, I prompted it to follow AGENTS.md.

[jbrockmendel]

nitpick: is this going to create an unnecessary python tuple object?

[jbrockmendel]

can we re-use some of this in the treat_tz_as_dateutil path?

[jbrockmendel]

Couple of test failures to figure out, but this looks like the right approach.

[kjmin622]

@jbrockmendel Thank you for your review! I've applied your feedback.
The tests failed because ZoneInfo and dateutil interpret offsets differently before the first transition (LMT era). For example, Africa/Lusaka shows a 2-second difference between the two libraries.
To address this, I modified the logic to use the original approach before the first transition, and the optimized approach after. (I've tried several approaches, but it seems impossible to fully resolve the performance issue for historical dates (before ~1900) where discrepancies occur between ZoneInfo and dateutil.)

[jbrockmendel]

ZoneInfo and dateutil interpret offsets differently before the first transition (LMT era)

This surprises me. Is there a minimal example?

[jbrockmendel]

This is needed to address the dateutil-vs-zoneinfo discrepancy?

[kjmin622]

No, this is just extracting common logic into a single function. The discrepancy is addressed by the fallback logic in tzconversion.pyx (the part you asked me to add comments to).

[jbrockmendel]

can you add comments explaining why this is necessary

[kjmin622]

ZoneInfo and dateutil interpret offsets differently before the first transition (LMT era)

This surprises me. Is there a minimal example?

@jbrockmendel
Here's a minimal example from my environment:

from zoneinfo import ZoneInfo
from dateutil.tz import gettz
from datetime import datetime

dt = datetime(1900, 1, 1)

# Africa/Lusaka: 2-second difference
print(ZoneInfo("Africa/Lusaka").utcoffset(dt))  # -> 2:10:18
print(gettz("Africa/Lusaka").utcoffset(dt))     # -> 2:10:20

# Africa/Sao_Tome: much larger difference
print(ZoneInfo("Africa/Sao_Tome").utcoffset(dt))  # -> -1 day, 23:23:15
print(gettz("Africa/Sao_Tome").utcoffset(dt))     # -> 0:26:56

Note that this discrepancy may not occur in all environments. Looking at the CI failure results, macOS passes while Ubuntu and Windows fail.
The tests pass when using the original logic (ZoneInfo.utcoffset()) for timestamps before the first transition.

[jbrockmendel]

@pganssle thoughts here on how to explain/handle the discrepancy?

[jbrockmendel]

I suspect this would also close #58962