Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
REF/DEPR: DatetimeIndex constructor #23675
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
REF/DEPR: DatetimeIndex constructor #23675
Changes from 17 commits
f8efbef
9d20bc9
aef3f4c
66ae42b
d0e8ee3
e1f4e17
d18e0df
a4c8c77
5dc5980
7e5587e
e94e826
7464d15
80b5dbe
3c822f1
ba7e5e8
3ba9da7
49c11e1
f1d3fd8
d44055e
1471a2b
11b5f6c
9f56d23
1c3a5aa
be4d472
145772d
7c99105
6b60da2
a7038bb
14d923b
c9dbf24
ce9914d
b3d5bb7
09c88fc
0367d6f
7cc8577
b3a096b
fd5af18
2cdd215
782ca81
03d5b35
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On which difference are you pointing here? The wall time vs utc ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DatetimeIndex(data=int64data, tz=tz)
treats the data as UTC times.DatetimeIndex(data=floatdata, tz=tz)
treats the data as wall-times. I would have expected that float data would be treated like int64 data.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah i agree this seems a little odd, these should just be cast to integer i think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jreback i think all comments except this one have been addressed (a few minutes away from green if all goes well). Changing this would be a breaking change, albeit a small one. Should we change now, deprecate now, or leave for a later PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok for this pr
yeah should fix / deprecate whatever is needed later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to verify: getting an you'll get an
np.int64
-dtyperesult
if and only ifinferred_tz
is not None?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why this addtiional level of try/except here? wouldn't this just raise anyhow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Presumably to re-raise the original exception if the fallback fails. This is the existing behavior.
I think @mroeschke and I are vaguely planning to revisit this before long and combine datetime_to_datetime64 into array_to_datetime, fixing the many idiosyncracies of these calls.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe i wasn't clear. I think you can simply remove the try/except and it will work the way it is now. (and same below).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the claim you're making is that it will raise under the same conditions, I agree. If the claim is that it will raise the same exception, I don't. i.e. if the
conversion.datetime_to_datetime64
were not inside its own try/except, then we could end up getting a TypeError in cases where we currently get a ValueErrorThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
really? i don't think that is actually possible. the original exception is re-raised here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jreback did this resolve the miscommunication?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again if datetime_to_datetime64 raises
won’t it just bubble up which is the same thing as a reraise here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds like a "no" on the resolving miscommunication. Did I at least accurately summarize your suggested change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jbrockmendel is correct here.
side-note, we could clarify all this with python-3 style
or six's https://pythonhosted.org/six/#six.raise_from, but it's probably just easier to wait until next month.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not resolved, but I see from @TomAugspurger which what i was getting at. i guess ok for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you could just write this as
might be more clear
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue with that is np.array(['20160405']) becomes np.array([20160405]) instead of 2016-04-05.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok sure