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.
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
REF/DEPR: DatetimeIndex constructor #23675
Changes from 24 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.
what is this difference from? why is this allowed
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.
Because
to_datetime
will return a Index of Timestamps in cases where there are mixed-tz or mixed tz-aware/naive entries. DatetimeIndex can't do that.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.
right and that is the correct behavior, actually DTI should just return a Index in that case, otherwise this is very confusing. I believe you have an issue talking about mixed-timestatmps. These should always just return an Index of objects. No conversion / inference should happen at all.
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 just remove the else and do the
raise TypeError(result)
at the endThere 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.
I think its worth distinguishing between hittable TypeError and defensive TypeError
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.
can you comment more then.
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.
sure
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
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.
same here, why the extra try/except?
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.
cam you be slightly more specific on 'fallback', e.g. when would this be triggered
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.
I'll flesh out the comment. The gist of it is if tz-aware datetime objects are passed and
utc=True
is not passed, thenarray_to_datetime
will raise aValueError
anddatetime_to_datetime64
will handle this case.It's a mess and is a big reason why I've been making array_to_datetime PRs: #24006 is an attempt to fix it, but there are some design questions @mroeschke and I are still batting around.
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 is this lowercase?
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.
This is how it is implemented in master. We'll improve this in the upcoming passes specific to
to_datetime
. Changing this behavior here is out of scope.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.
i find this allow_object pretty obtuse
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 alternative is to raise unconditionally in objects_to_datetime64ns, include the result in the exception args, then catch and extract it here. That was actually what I did in the first pass, but this is much more straightforward.