-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Offsets Roundup #18854
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Frequency
DateOffsets
Master Tracker
High level tracker for similar issues
Period
Period data type
Timezones
Timezone data dtype
Comments
4 tasks
2 tasks
david-liu-brattle-1
pushed a commit
to david-liu-brattle-1/pandas
that referenced
this issue
Jun 18, 2018
david-liu-brattle-1
pushed a commit
to david-liu-brattle-1/pandas
that referenced
this issue
Jun 19, 2018
Sup3rGeo
pushed a commit
to Sup3rGeo/pandas
that referenced
this issue
Oct 1, 2018
Still in use @jbrockmendel ? |
I think everything here that is still relevant has its own issue, which should have the Frequency label. Closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Frequency
DateOffsets
Master Tracker
High level tracker for similar issues
Period
Period data type
Timezones
Timezone data dtype
Confusion about offsets with
Period
. AFAICT the underlying issue is that DateOffset are for the most part intended to be used withdate_range
and its just a coincidence that some of them work withPeriod
.pd.Period('2013-12', freq='pd.offsets.BusinessMonthEnd())
raisesUnanchored Offsets
Quarter start/end offset confusion
Timezone issues
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)
Day
to behave likerelativedelta(days=1)
rather thantimedelta(hours=24)
RelativeDelta issues. Some of these may be solved or affected by #18329, #18226
dateutil.relativedelta
, so the issue seems to be confusingly similar kwarg options.NotImplementedError
)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:
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
normalize
should be accounted for in__eq__
(BUG: offsets normalize and __eq__ #17689) (closed by fix DateOffset eq to depend on normalize attr #21404)Tick
classes withnormalize=True
make sense? (Tick with normalize=True should be disallowed #21434)CacheableOffset
mixin is never usedBusinessMixin.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# 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.apply_index
?n==0
differently from all others.The text was updated successfully, but these errors were encountered: