REF: DatetimeLikeArray by TomAugspurger · Pull Request #24024 · pandas-dev/pandas (original) (raw)
TODO:
- DatetimeLikeArrayMixin.astype(int) ignores sign and size?
- _from_sequence too permissive?
- OK with DatetimeArray.view?
- tz vs. dtype in
DatetimeArray.__init__: REF: DatetimeLikeArray #24024 (comment) - Index._simple_new consistency: REF: DatetimeLikeArray #24024 (comment)
n.b.: right now I have a few other PRs in this branch (#23601, #23990, #24023). The eventual diff is at TomAugspurger/pandas@disown-tz-only-target...TomAugspurger:disown-tz-only-rebased.
Also, I would say this isn't quite ready for review yet, but I've been promising it for a while. I'm going to try to split off a bit more into separate PRs.
This implements DatetimeArray and TimedeltaArray, arrays for storing datetime
(tz naive or aware) and timedelta data.
High-level Design:
Everything here applies equally to TimedeltaIndex / TimedeltaArray, other than
references to DatetimeTZDtype. We don't have an ExtensionType for Timedelta.
DatetimeIndex's data is now a DatetimeArray, rather than an ndarray, and its dtype
is dtype::Union['datetime64[ns]', DatetimeTZDtype].
Class Hierarchy: We've split DatetimeIndex to compose a DatetimeArray,
rather than inherit it.
Old - DatetimeIndex: 
New - DatetimeIndex: 
New - DatetimeArray: 
Internals I've mostly given up here... Things are basically as they were
before, with the exception that DatetimeTZBlock now extends ExtensionBlock. In
particular tz-naive data is still stored in a DatetimeBlock, and is still
consolidatable. This isn't elegant, but we've lived with it for this long.
Future releases can clean it up, possibly when we rewrite / cythonize the block
manager, possibly before.
Types of changes
- Some changes from
x.view('i8')tox.astype('i8', copy=False)to
support getting i8 values from {ndarray, DatetimeIndex, DatetimeArray}.
We could revert those if we implemented DatetimeArray.view, but I don't
think we should. However, this is slower than.viewfor ndarrays, so
I'm going to find another way. - Many places where we did
series.valuesinstead ofseries._values. - Moves from PeriodArray / PeriodIndex to a base class. I've annotated these
withNB: Moved from... - Test skips / xfails. I intended to resolve all of these over the next few
days.
TODO:
- Split out DatelikeOps and TimelikeOps changes (REF: Refactor Date/TimeLikeOps #24038)
- independent tests for DatelikeOps & TimelikeOps methods on arrays.
- re-clean up the constructors. I may have some cruft from rebasing
- identify shared code in PeriodArray / PeriodIndex that can be moved up
- all the xfailed tests
- identify code that was special casing Datetime-dtyps (like
is_extension_type). - API: Series[datetimetz].unique: ndarray[object] or DatetimeArray?