fix: pd.to_numeric handling of datetime

[suzyahyah]

This PR handles all the cases of inconsistent datetime related pd.to_numeric handling from Issue 42380 and is compatible with pandas/io/parsers/base_parser.py

1. pandas/_libs/lib.pyx contains the core/common logic for datetime related pd.to_numeric handling
   

   pandas/pandas/_libs/lib.pyx

   Line 2453 in 083f01a

   elif convert_datetime and (PyDate_Check(val) or cnp.is_datetime64_object(val)):

2. pd.Timedelta will be returned as the direct value, and pd.Timestamp with Timezones are handled with the default np.datetime64 UTC conversion.
   


3. The removal of elif lib.is_np_dtype(values_dtype, "mM"): values = values.view(np.int64) in pandas/core/tools/numeric.py addresses the bug where int value of NaT are returned (Issue 42380).

4. Introduces convert_datetime flag in maybe_convert_numeric, as this function is used by both pd.to_numeric and in the base_parsers. The behavior for pd.to_numeric on datetimes is to convert, while the behavior on base_parsers is to not convert.

pandas/pandas/_libs/lib.pyi

Line 127 in 083f01a

convert_datetime: bool = ...,

• closes BUG: pd.to_numeric has an inconsistent behavior for datetime objects #43280
• Passes tests from BUG: pd.to_numeric has an inconsistent behavior for datetime objects #43280 and related linked PR discussions
• [] All code checks passed.
• Added an entry in the latest doc/source/whatsnew/v3.0.0.rst file

[WillAyd]

We definitely don't want to cast to float here.

This issue is really challenging and probably impossible to solve using the default (NumPy-backed) type system of pandas. I'm not sure there's anything to do unless that changes

[suzyahyah]

@WillAyd, Casting to float in addition to other dtypes is the existing pattern for handling null values in maybe_convert_numeric though.. The float array will be returned if there is null values in the series.

e.g.,

pandas/pandas/_libs/lib.pyx

Line 2411 in 82a0a2d

floats[i] = complexes[i] = val

pandas/pandas/_libs/lib.pyx

Line 2429 in 82a0a2d

floats[i] = uints[i] = ints[i] = bools[i] = val

[WillAyd]

The difference is that those all represent numeric operations, and having a precision loss may be an acceptable trade-off. I'm not sure that there's value in a precision loss with this operation; its not like a user would apply a mathematical algorithm to the result, so I would expect that retaining an accurate time representation is important

[github-actions]

This pull request is stale because it has been open for thirty days with no activity. Please update and respond to this comment if you're still interested in working on this.

[mroeschke]

Thanks for the PR but this PR has gone stale so closing