Closed
Description
Confusion about offsets with Period
. AFAICT the underlying issue is that DateOffset are for the most part intended to be used with date_range
and its just a coincidence that some of them work with Period
.
- DOC: Unclear documentation for Period Construction #4591 Unclear documentation for Period Construction
- Missing Periods for some DateOffsets #5091 Missing Periods for some DateOffsets
- No str for FY5253Quarter #12379 No str for FY5253Quarter
- Issues Creating Period with DateOffset as freq #4878 Issues Creating Period with DateOffset as freq, e.g.
pd.Period('2013-12', freq='pd.offsets.BusinessMonthEnd())
raises
Unanchored Offsets
- The docstrings/comments don't actually say what "isAnchored()` is supposed to mean. There is some explanation https://pandas.pydata.org/pandas-docs/stable/timeseries.html#anchored-offsets
- Feature request: Add annual offset that is not anchored #15685 Request for unanchored YearOffset
- YearOffset() raises AttributeError #7706 YearOffset() raises AttributeError
- BUG: seems that subtracting a YearBegin offset from an index loses the months/days #4804 BUG: seems that subtracting a YearBegin offset from an index loses the months/days
Quarter start/end offset confusion
- DOC: Anchored Offset Starting Quarter and Year defaults to JAN not DEC #17787 Anchored offset Starting Quarter and Year defaults to JAN not DEC
- Default for "Q" is not the same default for QuarterEnd #2885 Default for "Q" is not the same as default for "QuarterEnd"
- Parameter Name of startingMonth for QuarterEnd is Misleading #5307 Parameter Name of startingMonth for QuarterEnd is Misleading
- Quarter.onOffset looks fishy #18235 Quarter.onOffset looks fishy
- DEPR: QuarterBegin and BQuarterBegin return days that are not quarter beginnings #8435 DEPR: QuarterBegin and BQuarterBegin return days that are not quarter beginnings
Timezone issues
- Adding DateOffset(days=1) produces NonExistentTimeError #12156 Adding DateOffset(days=1) produces NonExistentTimeError, given example is
pd.date_range(pd.Timestamp('2015-1-1', tz='US/Eastern'), pd.Timestamp('2016-1-1', tz='US/Eastern'), freq='H') + pd.DateOffset(days=1)
- API: Wrong DateOffset behaviour with DST changes #16980 API: Wrong DateOffset behaviour with DST changes. I think the OP wants
Day
to behave likerelativedelta(days=1)
rather thantimedelta(hours=24)
- Lots of errors surfaced when running tests with hypothesis in [WIP] implement tests using hypothesis #18761
RelativeDelta issues. Some of these may be solved or affected by #18329, #18226
- DOC: hour/hours (and other plurals) based on dateutil.relativedelta #7418 BUG: hour/hours (and other plurals) should be the same as singulars. DateOffset behavior here just passes through to
dateutil.relativedelta
, so the issue seems to be confusingly similar kwarg options. - MonthOffset() gives increase of 1 day instead of 1 month #7707 MonthOffset() gives increase of 1 day instead of 1 month (This raises
NotImplementedError
) - BUG: seems that subtracting a YearBegin offset from an index loses the months/days #4804 goes here too
Perf
-
DateOffset.__eq__
(called fromPeriod.__eq__
) is very slow becauseDateOffset._params
is very slow. This could be improved a lot ifDateOffset
were immutable. Attempts to do this so far have run into pickle problems, see Tslibs offsets immutable #18224. Assistance requested.
Possible Bugs, needs confirmation:
- Week.onOffset looks fishy #18510 Week(weekday=None).onOffset will always return False, while I think it should always be True. (Closed by Fix bugs in WeekOfMonth.apply, Week.onOffset #18875)
- A bunch of offsets fail to satisfy
offset.onOffset(ts)
\Leftrigharrow(ts + offset) - offset == ts
. I think the latter is effectively the definition ofonOffset
in the general case, need confirmation that this is a bug.
Misc
- BUG: Cannot add non-vectorized DateOffset to empty DatetimeIndex #12724 BUG: Cannot add non-vectorized DateOffset to empty DatetimeIndex
-
normalize
should be accounted for in__eq__
(BUG: offsets normalize and __eq__ #17689) (closed by fix DateOffset eq to depend on normalize attr #21404) - Do
Tick
classes withnormalize=True
make sense? (Tick with normalize=True should be disallowed #21434) -
CacheableOffset
mixin is never used - liboffsets.WeekDay is not used outside of tests
- DateOffset._should_cache is never true
- DateOffset.isAnchored needs a docstring
- I screwed up a while back confusing
BusinessMixin.offset
withDateOffset._offset
. No real harm done, but should be reverted. Might be worth finding a different name thanoffset
-
BusinessHourMixin.apply
raises anApplyTypeError
with an incomplete error message - remove camelCase
- WeekOfMonth._from_name has a comment
# TODO: handle n here...
, same withLastWeekOfMonth
-
BQuarterBegin
has a comment# I suspect this is wrong for *all* of them
, could really use some clarification. -
YearOffset._get_offset_day
has a comment suggesting a more performant implementation may be available. -
FY5253.apply
has a couple ofassert False
statements for cases which presumably we don't expect to get hit. These should probably raise with a useful error message (or better yet, confirm that they will never get reached. - Does Tick need its own
apply_index
? - Easter.apply handles
n==0
differently from all others. - Not all DateOffsets are comparable #8386 missing comparison methods (Implement missing offset comparison methods #18738 should close this)