API: DatetimeIndex.get_loc(datetime) should require tzawareness compat?

[jbrockmendel]

dti = pd.date_range("2016-01-01", periods=3)
dti2 = dti.tz_localize("UTC").tz_convert("US/Pacific")

>>> dti.get_loc(dti2[0])
0
>>> dti2.get_loc(dti[0])
KeyError: Timestamp('2016-01-01 00:00:00-0800', tz='US/Pacific', freq='D')

ser = pd.Series(range(3), index=dti)
ser2 = pd.Series(range(3), index=dti2)

>>> ser.loc[dti2[1]]
1
>>> ser2.loc[dti[1]]
KeyError: Timestamp('2016-01-02 00:00:00-0800', tz='US/Pacific', freq='D')

get_loc is effectively an equality check, so I think it should behave like all our other comparisons and require tzawareness-compat. So all of these would raise KeyError.

xref #17920, #30819 (comment)

[jreback]

I agree with you here, we should be strict on tz awareness, though should'nt this actually raise a TypeError if its not tz compatible?

[jbrockmendel]

though should'nt this actually raise a TypeError if its not tz compatible?

The comparison would raise a TypeError, but get_loc would catch and re-raise with KeyError I think. I'll be double-checking that we're consistent about this throughout (with docstrings)

@jorisvandenbossche any thoughts here before i move forward on this?

[jorisvandenbossche]

I think the examples above might be a bit misleading. The original tz-naive timestamps are not in the dti2, so that is the reason you are getting a key error (not because the tzawareness is not compatible). Constructing one specifically actually works:

In [41]: ser2 
Out[41]: 
2015-12-31 16:00:00-08:00    0
2016-01-01 16:00:00-08:00    1
2016-01-02 16:00:00-08:00    2
Freq: D, dtype: int64

In [42]: dti[1] 
Out[42]: Timestamp('2016-01-02 00:00:00', freq='D')  # <--- this time of 00:00 is not in the series

In [43]: ser2.loc[dti[1]]                            # <--- so the key error is expected
...
KeyError: Timestamp('2016-01-02 00:00:00-0800', tz='US/Pacific', freq='D')

In [44]: ser2.loc[pd.Timestamp("2016-01-01 16:00:00")]    # <--- also different tz, but works
Out[44]: 1

For tz-aware series/index, I think this actually makes some sense. At least, for example I expect "tz-naive" strings to work.

The other way around (indexing a tz-naive index with a tz-aware timestamp), on the other hand, seems less useful to me.

[TomAugspurger]

What are the proposed behavior here?

• @jbrockmendel: DatetimeIndex.get_loc(key) requires that index.tz == key.tz, else a KeyError is raised, regardless of the value of key?
• @jorisvandenbossche: Allow DatetimeIndex.get_loc(key) when key doesn't have a tz by localizing to the index's tz? And raise if the tz mismatch?

@jorisvandenbossche is the second part of my summary correct, that get_loc raise when both are tz-aware and are mismatched?

@jbrockmendel what's your proposal for indexing a DatetimeIndex with a tz-naive key, when the localized key is in the index?

[jbrockmendel]

what's your proposal for indexing a DatetimeIndex with a tz-naive key, when the localized key is in the index?

dti_tz[stamp_naive] raises KeyError, like any non-matching-type would. This makes get_loc behave like every other comparison-like method.

requires that index.tz == key.tz, else a KeyError is raised, regardless of the value of key?

No, only tzawareness-compat, so no naive/aware mixing. If both are tzaware but different timezones, it converts (again, like every other comparison method; setitem-like methods require matching timezones)

[jbrockmendel]

closed by #36148