DEPR: allowing non-round floats in to_datetime/DatetimeIndex/Timestamp/...

[jbrockmendel]

A frequent pain point (#53198, #52286) since we introduced non-nano dt64 support is that to_datetime(x, unit=...).unit does not necessarily mach the user's given unit. This is behavior is documented but still confusing.

We could change/deprecate the behavior so that the output unit matches the input unit. The main things standing in the way of that:

1. For float inputs that would introduce unwanted rounding. i.e. ATM pd.Timestamp(1.5, unit="s") currently returns the fractional second, but if we changed this would round down (users might be surprised that this always rounds down as opposed to round-nearest)
2. For units lower than "s" we would have to return closest-supported-unit. We do that in a bunch of places so it isn't a huge deal, but it does mean the policy is more complicated than "output matches input".

The first here seems to be the problematic one. But AFAIK floats just aren't passed that often. When they are, I suspect they are usually round but cast to float so that NaN can be set. Does anyone have a use case for non-round floats in these functions?

If not, we should deprecate the current support, which will un-block allowing "unit" to behave more intuitively.

cc @MarcoGorelli

[MarcoGorelli]

By 'deprecate the current support', do you mean that pandas should error if non-round floats are passed? If so, I'd be very much on board

[jbrockmendel]

raise or round, either way would be OK with me

[MarcoGorelli]

cool - I'd prefer raising tbh

[jbrockmendel]

Looks like we get non-round floats from SAS. We call to_datetime from io.sas.sas7bdat._convert_datetimes with floats that can represent fractional seconds.

edit: im having trouble determining what resolution these are supposed to represent in the SAS format. Good reason not to use floats for this!