BUG: to_datetime with floats and unit not matching Timestamp #56037
Conversation
mroeschke
added
the
Non-Nano
|
Thanks @jbrockmendel |
|
This seems to have caused a pretty bad performance regression |
| @@ -232,6 +233,7 @@ def test_to_timedelta_on_missing_values_list(self, val): | |||
| actual = to_timedelta([val]) | |||
| assert actual[0]._value == np.timedelta64("NaT").astype("int64") | |||
|
|
|||
| @pytest.mark.xfail(not IS64, reason="Floating point error") | |||
There was a problem hiding this comment.
I think this is incorrect: I'm getting an XPASS here.
My guess is that you've hit this on i386, probably due to i387 weirdness. However, this wouldn't affect other 32-bit architectures or i386 builds with -mfpmath=sse. Gentoo is switching towards the latter since i387 is simply causing too many floating-point issues.
There was a problem hiding this comment.
A PR to make the xfail condition more precise would be welcome
There was a problem hiding this comment.
I know but I honestly have no clue how to detect the right case. At this point, I can think only of two options: either removing the xfail and ignoring i387-based x86 to support other 32-bit setups, or using an approximate comparison instead.
doc/source/whatsnew/vX.X.X.rstfile if fixing a bug or adding a new feature.The edited sas test is unfortunate but i think OK overall. Will revisit once #56014 is addressed. Also i expect that behavior to change in the not-too-distant future to return non-nano anyway.
In a follow-up I'll try to de-duplicate cast_from_unit and cast_from_unit_vectorized.