BUG: .loc Indexing with pyarrow backed DatetimeIndex does not allow string comparison about pandas

[jbrockmendel]

I see from the linked PR that you don't think this should be supported. Curious to hear your reasons why before anyone works on it.

I linked this there bc the expectation that this would already work bc the only difference is in how the DatetimeIndex is "backed" is incorrect (the Index in question is not a DatetimeIndex at all). I think part of that incorrect expectation is linked to the term "backend" and hope that using a more accurate term might avoid misconceptions.

As to the actual behavior, I'd be fine with it, though I expect the implementation would be very messy to the point where saying "convert to a DatetimeIndex" might be easier.

[SarthakNikhal]

@WillAyd Can I work on this issue? I did not know arrow is supposed to work with pandas....

[WillAyd]

@jbrockmendel I see from the linked PR that you don't think this should be supported. Curious to hear your reasons why before anyone works on it.

pa.timestamp and pd.Timestamp share a lot of the same architecture (save missing value handling) so I think converting from one to another should be seamless. I'm definitely sympathetic to not trying to make everything they do the same, although indexing like this feels useful. I do think part of the confusion here could stem from the fact that we do not have a logical "timestamp" type, only physical

I came across this reading a CSV file with the pyarrow backend, which was great for strings but then didn't help me at all with timestamps.

[WillAyd]

Looks like this is actually a duplicate of #53154 - closing to keep the discussion there