INT/CLN: remove to_datetime from class methods

[jreback]

see #8184
related #8185

Index.to_datetime currently exists but really no need for this as pd.to_datetime subsumes this functionaility (and is more general). and just pollutes the interface.

so remove:

• Timestamp.to_datetime
• DatetimeIndex.to_datetime DEPR: Deprecated Index.to_datetime #14096
• Index.to_datetime DEPR: Deprecated Index.to_datetime #14096
• NaT.to_datetime
• PeriodIndex.to_datetimeDEPR: Deprecated PeriodIndex.to_datetime #14113

(and fix the parser to call directly try the conversion / use a helper function).

[gfyoung]

I actually would like to keep Timestamp.to_datetime. That's useful function I've found for converting from native pandas datetime objects to generic Python datetime ones. In addition, pd.to_datetime only returns Timestamp and not datetime.

[jorisvandenbossche]

See also #5612 (wihch can be closed as well when this is deprecated)

I actually would like to keep Timestamp.to_datetime

There is Timestamp.to_pydatetime that does the same and is more consistent with the name for DatetimeIndex etc

[gfyoung]

@jorisvandenbossche : Ah, that's a good point. I wasn't actually familiar with the to_pydatetime method, though given what you said about consistency, we should look into deprecating that.

[gfyoung]

@jorisvandenbossche : On the topic of deprecating to_datetime, any reason why we need to keep NaT.to_datetime when pd.to_datetime(NaT) will do just fine?

[jreback]

I would remove Timestamp.to_datetime as well (well deprecate it).

[gfyoung]

@jreback : Yes, that I can now agree with given what @jorisvandenbossche said earlier. What about NaT.to_datetime?

[jreback]

yes that as well. no vestages, check Period as well pls.

[gfyoung]

@jreback : Period has no such method 😄

[gfyoung]

Also, checkoff the Index and DatetimeIndex boxes but add one for NaT.

[gfyoung]

I just discovered that PeriodIndex has a to_datetime method as well. However, this case is somewhat unique because you can't call pd.to_datetime on it (an error is raised because it is the wrong type). Nevertheless, PeriodIndex.to_datetime does convert to DatetimeIndex and hence behaves similarly to pd.to_datetime.

The implementation for PeriodIndex.to_datetime seems quite tailored to PeriodIndex (it calls a special helper to_timestamp) and to port it to the general to_datetime does not seem optimal. Thoughts on how this should be refactored so that PeriodIndex.to_datetime can be deprecated?

[jreback]

sure this can be removed
that is the point of to_timestamp which is the canonical way

[gfyoung]

Let's add it to the list then since it will require slightly different treatment.

[jorisvandenbossche]

Is it needed to remove the PeriodIndex.to_datetime? As that seems a valid method to me, as the counterpart of DatetimeIndex.to_period ?

[jorisvandenbossche]

Ah, I see that this functionality is covered by PeriodIndex.to_timestamp (sorry, should have looked better to your comment).
But, personally, I like the to_datetime in this case, as it converts to a 'Datetime'Index (the current docstring of PeriodIndex.to_datetime is in any case totally incorrect)

[gfyoung]

@jorisvandenbossche : Agreed, the doc string is not right because it inherits it from Index. IMO pd.to_datetime should be the only to_datetime method exposed to unify the interface.

One option is to add a check for PeriodIndex in to pd_datetime so that it calls PeriodIndex.to_timestamp (currently, an error is raised). Thoughts?

[jorisvandenbossche]

I see that there is also a Series.to_timestamp (and no Series.to_datetime) to convert period index to datetime index. So probably for consistency, to_timestamp is indeed to be preferred and OK with deprecating PeriodIndex.to_datetime

(accepting Periods in to_datetime is a separate issue I think)

[gfyoung]

Ah, okay, fair enough. Will leave that part alone then.