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

[jbrockmendel]

• closes API: Series(mixed_datetime_and_ints, dtype="M8[ns]") vs DatetimeIndex(same) mismatch #49037 (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

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?

[mroeschke]

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

[jbrockmendel]

i dont think so, no

[mroeschke]

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

[jbrockmendel]

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

[mroeschke]

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

[jorisvandenbossche]

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]

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]

failures unrelated

[mroeschke]

LGTM

[mroeschke]

Thanks @jbrockmendel