Datetime resolution coercion #10249
Datetime resolution coercion #10249
Conversation
| parse_dates={'datetime': ['week', 'sow']}, | ||
| index_col=['datetime', 'prn']) | ||
|
|
||
| self.assertEqual(df.index[0][0], datetime(2013, 11, 3, 19)) |
There was a problem hiding this comment.
construct an actual frame and use assert_frame_equal
|
For some reason 706b8df fails Travis on my fork. I can't figure out why. The error doesn't seem to be related to my testing function (which was the only thing I changed, apart from importing |
|
pull from master again and rebase. i fixed the issue. |
|
Still failed Travis in my fork |
|
oh, that was a generic message I sent out. You might have a specific issue then. |
| new_col = parser(*to_parse) | ||
| if hasattr(new_col, 'dtype') and any(r in str(new_col.dtype) for r in |
There was a problem hiding this comment.
what is all this for ? this should not be necessary
There was a problem hiding this comment.
What? Oh, man. That was the first fix I came up with, scrubbed in favor of your suggestion. No idea how it made its way in.
the two first commits in the PR, b6d07b4 and 7d6f7c4, should be reverted. How do you propose I do this?
There was a problem hiding this comment.
rebase on master, and just delete them, see http://pandas-docs.github.io/pandas-docs-travis/contributing.html#getting-started-with-git
you basically
git rebase -i master
There was a problem hiding this comment.
Oh, I see what's wrong. I had previously committed the two unwanted commits to my fork's master branch (before pulling the updated master branch). I tried git revert but that caused merge conflicts so I reset. How can we solve this with a minimum of mess? Should we just close this PR and I'll open a new one with the good commits?
There was a problem hiding this comment.
you just rebase it and delete the commits you don't want.
There was a problem hiding this comment.
I don't know how to "rebase" the master branch. I tried git rebase -i on master, and it just said noop where the commit list should be.
|
try |
|
There we are. Ended up adding pydata/pandas as a remote and rebasing this PR branch on top of that. Diff seems correct now. |
|
Build passed, will this be merged? Or is anything else needed? |
|
@cmeeren thanks for the nudge. I think this looks pretty much good now. All we need now is a release note in what's new in Once you've done that, please squash to one commit. |
|
Oh no, again the thing with the wrong commits being included on rebase. I'll rebase onto |
|
There we are. |
| @@ -152,3 +152,4 @@ Bug Fixes | |||
|
|
|||
| - Bug to handle masking empty ``DataFrame``(:issue:`10126`) | |||
| - Bug where MySQL interface could not handle numeric table/column names (:issue:`10255`) | |||
| - Bug where ``read_csv`` and similar failed if making ``MultiIndex`` and ``date_parser`` returned ``datetime64`` array of other time resolution than ``[ns]``. | |||
There was a problem hiding this comment.
add the issue number at the end
|
thanks! |
|
Oh, I thought you wanted the issue number in the "whatsnew" document. I hadn't pushed that yet. But you're the boss. :) |
|
I forgot I asked you, and just did it. 0a428e7 thanks! |
|
👍 |
Fixes #10245
Without this fix, if the
date_parsefunction passed to e.g.read_csvoutputs anp.datetime64array, then it must be ofnsresolution. With this fix, all time resolutions may be used.