BUG: Cannot create third-party ExtensionArrays for datetime types (xfail) by xhochy · Pull Request #34987 · pandas-dev/pandas (original) (raw)
I would prefer to fix this myself though.
Sounds good. Is this a use case you have a need to get working near-term, or more of a Principle Of The Thing? I ask because...
I just need a pointer at which code section I should apply a fix.
This is pretty daunting, as I expect this is scattered across the code. There are lots of places where we either a) implicitly assume nanoseconds or b) check dtype.kind in ["M", "m"]
(much more performant than the is_foo_dtype
checks)
Should I change the order in pandas/pandas/core/internals/blocks.py so that we only create a DatetimeTZBlock for pandas-provided datetime-based ExtensionArrays
That will probably be part of a solution.
or shouldn't is_datetime64tz_dtype return True for my ExtensionDtype?
I'd be very reticent to make that change, since I think a lot of code expects that to imply its getting our Datetime64TZDtype. Maybe a is_3rd_party_ea_dtype
that we would check for before checking for any 1st-party dtypes? That runs into the "ideally we should treat 3rd party EAs symmetrically with 1st-party" problems.
So getting back to the motivation: how high a priority is this?
One thing I can unambiguously encourage is more tests, even if xfailed:
- what happens if you pass one of these to the DatetimeIndex constructor? vice-versa?
- what happens if i do DatetimeIndex.astype(this_new_ea_dtype)
- addition/subtraction with the gamut of datetime/timedelta scalars/arrays we already support?
- How does this behave if you stuff it inside a Categorical/CategoricalIndex?