-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Pandas doesn't accept dtype=np.datetime64 #8004
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
all datetimes are internally (and converted from) kept as and conversions are already way complicated. You are certainly welcome to try to fix this. but is their an actual usecase? |
these kinds of dtypes are also parameterized whereas things like int64, float64 etc are not, so it doesn't make sense to pass it in unparameterized. also empty series of datetimes are very edge-casey what's the motivation? i would even argue that passing in the dtype to series is unnecessary 95% of the time (pandas is pretty good about doing the right thing), if you need to coerce to datetimes use |
I wanted to explicitly create a Series that contained datetimes, and the docstring of
so I assumed that I could pass in a numpy type. Perhaps it's just a matter of clarifying the docstring? Whilst I used an empty series as a minimal reproducible example, this does occur for non-empty series too:
This behaviour does actually work with other numpy dtypes, e.g. |
you can create and then do do you have non-trivial use case? would help us evaluate whether this is necessary |
@Wilfred this is the point of |
If all you want is a workaround, note that you can do this:
The problem is that numpy doesn't make it easy to get from |
that's because |
even though for some reason numpy still lets you think that it does
|
I don't mean a |
we are talking about |
Whoops, yes. The point still stands. |
OK, perhaps the best solution would be to throw an explicit error about parameterized types, so the user knows how to fix. Something like:
|
I was under the impression that from pandas's point of view, there is one true
Currently all of these raise. |
The point was to be explicit and make Tests / impl shoulld be straightforward. Just never had a reason to actually pass anything like this as usually this is inferred e.g. which is actually quite tricky because you first have to interpret it and it CAN be ambiguous |
Closed by #23392 |
The following workaround works:
but I would expect passing in the numpy type to work too.
The text was updated successfully, but these errors were encountered: