CLN: de-duplicate boxing in DTI.get_value

[jbrockmendel]

Also add a dedicated test or it to hit currently un-covered case of np.datetime64 key. That case works in master, but doesn't go through the expected code path

[jbrockmendel]

the removed code here is duplicated in get_value_maybe_box

[jbrockmendel]

@jreback @jorisvandenbossche related to this PR I'm trying to de-duplicate the localization going on in _get_value_maybe_box. Back in #17920 it was decided to localize naive-looking strings when doing lookups on a tzaware DTI, but I'm surprised that we are doing the same for datetime objects (and AFAICT also np.datetime64, but we dont test that case)

The relevant test is in tests.series.indexing.test_datetime, pulling out the pertinent part:

rng = date_range("1/1/1990", periods=N, freq="H", tz="US/Eastern")
ts = Series(np.random.randn(N), index=rng)

[...]
# repeat all the above with naive datetimes
result = ts[datetime(1990, 1, 1, 4)]
expected = ts[4]
assert result == expected

When I change the behavior of get_value to not cast tznaive datetime objects, this lookup raises (which I thought was the correct behavior, but apparently not?). Looking at the blame for this test, it has been around for a long time.

Changing this would be non-trivial because it turns out that getitem[scalar] goes through DTI.get_value but slicing and setitem etc go through different paths.

I guess there's not really a question here, just opening it up for comments.

[jreback]

about your comment: #30819 (comment)

yeah this is the implict conversion of strings only to a local timezone when they are naive (the strings) and the indexing is on timezone aware indexes. note that this does not apply to timestamps which must be explicityly timezoned.

seems reasonable, but feel free to open an issue if more questions.

ideally we should try to limit the indexing paths, but there is a lot going on so not sure how easy this is.

[jreback]

thanks