ENH: fallback to zoneinfo Python API (for correct tz localization) for distant dates#65733
Conversation
| and info.deltas[delta_idx - 1] >= 0 | ||
| ): | ||
| delta_idx = delta_idx - 1 | ||
| if info.use_zoneinfo and new_local > info.tdata[info.ntrans - 1]: |
There was a problem hiding this comment.
TODO: I have to check (and test) a bit for new_local close that last transition value, because AFAIK new_local is supposedly local time but tdata are UTC values.
So in theory the local time could still be smaller than the last transition value, while it is actually (in UTC) beyond it. But it might be that this is fine, since offsets beyond that last transition value should still be correct until the next transition?
(in theory one could probably create a tz rule with two transitions only a few hours apart, but that should not occur in practice?)
There was a problem hiding this comment.
In this case we'd still get the correct result, just not take the fastpath?
| "start_ts, tz, end_ts, shift", | ||
| [ | ||
| ["2015-03-29 02:20:00", "Europe/Warsaw", "2015-03-29 03:00:00", "forward"], | ||
| ["2018-03-25 02:20:00", "Europe/Warsaw", "2018-03-25 03:00:00", "forward"], |
There was a problem hiding this comment.
The year is only changed here so that all values in this parametrization have the same year (below there are existing cases with 2018), such that replacing with the distant year works for all cases
| and info.deltas[delta_idx - 1] >= 0 | ||
| ): | ||
| delta_idx = delta_idx - 1 | ||
| if info.use_zoneinfo and new_local > info.tdata[info.ntrans - 1]: |
There was a problem hiding this comment.
should we calculate info.tdata[info.ntrans - 1] just once?
|
I think this is a reasonable approach, haven't close-reviewed yet. |
2 participants
Attempt for the third option mentioned in #65712: Use our fast-path for a "normal" range (eg up to 2100) to cover most use cases, and then for dates after that, use the zoneinfo python API directly as a slower fallback.
This is adding back a modified version of #65481, but then inside the general for-loop to fallback per value, instead of always for zoneinfo tz objects.
I tried parametrizing some of of the
tz_localizetests for a current year and a distant year, to have some coverage for this fallback.If we would go with this PR, then #65705 (expanding the cached transition data's range to 2262 instead of 2100) might not be needed
doc/source/whatsnew/vX.X.X.rstfile if fixing a bug or adding a new feature.