Skip to content

Conversation

@jbrockmendel
Copy link
Member

@jbrockmendel jbrockmendel commented Oct 26, 2022

cc @jreback this goes a long way towards getting Series/Index constructors to match, but i dont see the reason for the current behavior, do you remember?

to_datetime(arr, errors="raise", cache=cache)
# GH#49037 pre-2.0 this raised, but it always worked with Series,
# was never clear why it was disallowed
result = to_datetime(arr, errors="raise", cache=cache)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a test where unit and/or origin is also specified in this mixed cases?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i dont think so, no

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this test be easily added? ( I would expect unit and origin only applicable to the ints and ignored for datetimes )

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

origin is only relevant with numeric dtypes, so won't go through array_to_datetime

Copy link
Member

@mroeschke mroeschke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally +1 to have [ints, datetimes] be supported, especially in to_datetime

@mroeschke mroeschke added the Datetime Datetime data dtype label Oct 28, 2022
@jorisvandenbossche
Copy link
Member

I commented on the issue (#49037), I think I am also +1 on allowing the mixture (although I don't like that specific behaviour, it seems the most consistent if we want to have generally applicable rules)

@jbrockmendel one thing I am wondering: the allow_mixed keyword, that's not useful to keep for potential stricter behaviour? (although I assume it's not actually useful for "only datetime objects", since allow_mixed=False can also mean that you have only ints)

@jbrockmendel
Copy link
Member Author

one thing I am wondering: the allow_mixed keyword, that's not useful to keep for potential stricter behaviour? (although I assume it's not actually useful for "only datetime objects", since allow_mixed=False can also mean that you have only ints)

Assuming you mean in array_to_datetime. I don't think its particularly useful, but its also not harmful (except for not being tested). For only-datetime-objects (i.e. the strict from_scalars) i think it may be cleaner to implement a new dedicated function than further overloading array_to_datetime.

@jbrockmendel
Copy link
Member Author

failures unrelated

Copy link
Member

@mroeschke mroeschke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mroeschke mroeschke merged commit 8d8d3cf into pandas-dev:main Nov 17, 2022
@mroeschke
Copy link
Member

Thanks @jbrockmendel

@jbrockmendel jbrockmendel deleted the api-allow_mixed branch November 17, 2022 01:39
MarcoGorelli pushed a commit to MarcoGorelli/pandas that referenced this pull request Nov 18, 2022
…ndas-dev#49348)

* API: allow mixed-datetimes-and-ints in to_datetime, DatetimeIndex

* typo fixup

* typo fixup, update import

* mypy fixup
mliu08 pushed a commit to mliu08/pandas that referenced this pull request Nov 27, 2022
…ndas-dev#49348)

* API: allow mixed-datetimes-and-ints in to_datetime, DatetimeIndex

* typo fixup

* typo fixup, update import

* mypy fixup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Datetime Datetime data dtype

Projects

None yet

Development

Successfully merging this pull request may close these issues.

API: Series(mixed_datetime_and_ints, dtype="M8[ns]") vs DatetimeIndex(same) mismatch

3 participants