Open
Description
This was discussed a few dev calls ago, merits an issue.
Now that we support non-nano TImestamp/datetime64, many of the motivating use cases for Period can be handled there. If we further extended this support to the other np.datetime64 units, could we obviate the need for Period altogether?
Upsides (after deprecations are enforced)
- Smaller API
- Avoid confusion about DateOffsets vs Period freqs (Missing Periods for some DateOffsets #5091, BUG: Timestamp.to_period() fails for freq="MS" #38914, several others I think)
- Big chunks of Resample is just broken with PeriodIndex (xref DEPR: Resample with PeriodIndex? #53481, BUG: Up-Resample data with PeriodIndex has unexpected behavior #42763)
- Makes NDFrame to_timestamp, to_period methods unnecessary
- Addition/subtraction avoids object dtype (xref BUG: In master, math with periodindex + index of offset produces wrong result #50162)
- Avoid ambiguity of "freq" meaning something different for DTI/TDI vs PI (xref API: make 'freq' mean the same thing for PeriodIndex as DTI/TDI #47227, Why does
infer_freqraise an error for PeriodIndex? #6771)
Some sticking points come to mind
- Period units that don't have corresponding np.datetime64 units
- BDay (xref DEPR: Period[B] #53446 that seems DatetimeIndex[D] with freq="B" should be good enough?)
- Week-with-anchor
- Quarter
- Year-with-anchor
- Period is stricter than Timestamp/dt64 about not allowing operations between periods with mismatched freqs/units
- Would we want to support tz-awareness for lower-reso units? Timezones can have minute (maybe even higher in principle?) resolution, which would be very weird to pin to e.g. a dt64[h]. On the flip side, supporting tz for some units but not others might be akward.
- Period supports integer multiples e.g.
freq="2ms"which we don't currently support for dt64 (though numpy does, so it is possible) - PeriodIndex has slightly different partial-indexing behavior in get_loc than DatetimeIndex. Someone might be relying on that?