Description
An example of the behavior that should be deprecated:
In [2]: dti = pd.date_range('2016-01-01', periods=3)
In [3]: dti + 1
Out[3]: DatetimeIndex(['2016-01-02', '2016-01-03', '2016-01-04'], dtype='datetime64[ns]', freq='D')
In [4]: dti[1] + 100
Out[4]: Timestamp('2016-04-11 00:00:00', freq='D')
In [5]: tdi = pd.timedelta_range('1D', periods=3)
In [6]: tdi - 1
Out[6]: TimedeltaIndex(['0 days', '1 days', '2 days'], dtype='timedelta64[ns]', freq='D')
In [7]: tdi[-1] - 1
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-7-ac830ffbe976> in <module>()
----> 1 tdi[-1] - 1
TypeError: unsupported operand type(s) for -: 'Timedelta' and 'int'
This TypeError
occurs because TimedeltaIndex._box_func
does not pass self.freq
to Timedelta
, and is one of many ways that this behavior introduces inconsistencies into the code.
-
Integer add/sub for DTI/DTI just passes through to
self.shift(n)
, so there is a ready alternative. -
This behavior is inconsistent between
DatetimeIndex
andSeries[datetime64]
(BUG: Series(DTI/TDI) loses the frequency information from original DTI/TDI #20937) (same for TDI) -
freq
is not really a useful part of the Timestamp or Timedelta abstraction (DEPR: remove freq attribute of Timestamp? #15146). -
The existence of a
Timestamp.freq
gives many users the incorrect impression thatPeriod.freq
behaves the same way (DOC: Unclear documentation for Period Construction #4591, Issues Creating Period with DateOffset as freq #4878, Missing Periods for some DateOffsets #5091, No str for FY5253Quarter #12379) -
to_datetime fails to preserve
freq
in some cases (need to track down the issue) -
Timestamp and Timedelta
__eq__
ignoresfreq
Bottom line: DTI/TDI/Timestamp/Timedelta arithmetic with integers should be deprecated to a) cut out a bunch of hard-to-maintain code and b) avoid internal inconsistencies.