-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
BUG: preserve frequency across Timestamp addition/subtraction (#4547) #6560
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
Conversation
you might want to take a crack at #4553 something up with Travis ATM |
What is the |
Not sure what you mean by "taken into account" - I can add it somewhat simply as in #4553 (just something like "freq='D'") but maybe you mean something more? In terms of uses, in addition to the "next_calendar_quarter = current_calendar_quarter + 1" usage in #4547 (which is perhaps not advisable when one can increment by the more explicit tseries.offset objects) I see that freq is used in Timestamp.to_period(), which gets a bit of a demo in http://pandas.pydata.org/pandas-docs/stable/10min.html . |
@rosnfeld What I meant by taken into account was that when calling
|
@cancan101 don't confuse the issue a repr is something that can be copy pasted to reverse the object this is not pretty-printing |
@jreback I understand repr and str are not the same. I was just suggesting that it would be cool for the |
no problem with that. can you propose some possibilities (e.g. Timestamps / Periods with and w/o freqs for various freqs) |
@rosnfeld can you rebase on current master and force push....had some issue with caching of some deps...shouldl be resolved now |
Yup, done and Travis seems happy now. |
BUG: preserve frequency across Timestamp addition/subtraction (#4547)
@rosnfeld thanks again! don't be shy about looking for more PR's! |
@cancan101 - I played with your suggestion a little bit as it sounded cool, but after working through some examples I'm not sure I am in favor of it. In my understanding, Timestamps represent an instant in time, whereas Periods represent a span of time, and I think we should present these differently to users. One may have monthly samples of some quantity, but if it's actually a point-in-time sample, taken at say the end of the month vs the start of the month, I think I'd like to see that daily level of detail rather than just seeing the month. If one instead is working with some quantity averaged over the month (e.g. average temperature over a month) then it makes more sense to just show the month, but then I think one should be using a Period rather than a Timestamp. Admittedly I haven't played with Periods much, I've just read about them in the Python for Data Analysis book. |
@rosnfeld What you say makes sense. That being said, why does the Timestamp even have an offset to begin with? |
@cancan101 Right, good question - I think it's because a Timestamp really can have a "frequency", it's an instant-in-time sample taken every so often. I don't think pandas does too much with this information at present. |
The freq on a Timestamp facilities operations w.r.t. that frequency, e.g. e.g.
|
closes #4547
My second PR, on basically the same code.
Assuming people agree with my comments on #4547 (that users adding timedeltas that don't match frequencies better know what they are doing), then this would be my submission.
I'm also assuming that something is up with Travis and it is not anything I have done - nosetests passes fine for me though Travis still dies more or less at startup, while it didn't on older code. That problem is true of builds not including any code I have added, e.g. https://travis-ci.org/pydata/pandas/jobs/20167915 . Maybe something in PR #6068, or does this kind of thing happen from time to time?