-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
DatetimeIndex.get_slice_bound(...) raises TypeErrors for unexpected YYYY-MM-DD/datetime.date/Timestamp combinations #35690
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Sorry that this issue hasn't had followup sooner. Note that the "ix" option has been removed since 1.1.0, but the results are identical with other I agree with your observations but just to comment:
|
Thank you for investigating. If it would be helpful, I can directly send you some non-trivial unit tests that I have written to exercise these observations. It is very much a superset of what is reported above. |
Sure if you have any test cases that test |
I think the important thing is internal consistency. date objects are not allowed for DatetimeIndex inequality comparisons, so shouldn't be allowed here. (or the comparison behavior should be changed xref #35466)
I think that is a bug, and that we should not be allowing naive timestamps here. there was a long discussion a couple years back that resulted in allowing naive strings, but i dont think allowing naive timestamps was ever even proposed. |
If naive strings contain the same information as naive timestamps, I don't see why they should be treated differently (though I'll defer to precedent that I don't know). An object is naive or it is not. |
I am not 100% knowledgeable of what |
You're right. Note that #31501 was closed by #31521, where I commented that the change was OK but should be deprecated for internal consistency. We're inconsistent because passing a date object to |
Below find a handful of reproducible observations in Pandas 1.0.5 re:
DatetimeIndex.get_slice_bound(...)
where I'm genuinely not sure what the correct behaviors should all be. Some of these appear related to #34077 in thatslice_locs(...)
usesget_slice_bound(...)
under the covers.Observations inlined and expected behaviors discussed afterwards:
Discussion:
Again, observations inlined and expected behaviors discussed afterwards:
Discussion:
The text was updated successfully, but these errors were encountered: