Pandas version checks
-
[x] I have checked that this issue has not already been reported.
-
[x] I have confirmed this bug exists on the latest version of pandas.
-
[x] I have confirmed this bug exists on the main branch of pandas.
Reproducible Example
import pandas as pd
# https://www.timeanddate.com/time/change/belgium/brussels?year=2022
ts = pd.Timestamp("2022-10-30", tz="Europe/Brussels")
offset_explicit_keyword = ts + pd.offsets.DateOffset(days=1)
offset_default_value = ts + pd.offsets.DateOffset(1)
assert offset_explicit_keyword == offset_default_value
Issue Description
According to the documentation, pd.offsets.DateOffset(1)
should be the same as pd.offsets.DateOffset(days=1)
During instanciation the following function is called : https://github.com/pandas-dev/pandas/blob/bc6ad140daf230c470fef92bec598831d4f94a16/pandas/_libs/tslibs/offsets.pyx#L284-L334
For pd.offsets.DateOffset(1)
it returns timedelta(days=1), False
, whereas for pd.offsets.DateOffset(days=1)
this returns relativedelta(days=1), True
. This causes inconsistencies in the behavior of the two near DST transitions.
Expected Behavior
Either the doc can be changed or we ensure pd.offsets.DateOffset(1)
equals pd.offsets.DateOffset(days=1)
by my understanding this could be done in the following way
cdef _determine_offset(kwds):
if not kwds:
+ from dateutil.relativedelta import relativedelta
+
# GH 45643/45890: (historically) defaults to 1 day
- return timedelta(days=1), False
+ return relativedelta(days=1), True