-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: fillna('') does not replace NaT #11953
Comments
cc @ywang007 |
xref. #15533 @jreback I think this keyword would be a 👍. This would be a way of harmonizing the for/against validating forcefully/weakly that are under discussion at PR#15587. Once that PR is added, this behavior could presumably be added as a single I think it's worth considering adding similar behavior to methods implementing |
This behavior no longer coerces to object. I supposed it could use a test orthoganal to the enhancement request
|
Actually I think this is a bug and the original behavior was correct.
|
Hello, just to add to this thread. I have encountered this bug when upgrading pandas from 1.2.5 to 1.3.3 (it looks like this bug was introduced in version 1.3.0). When using fillna or replace on a datetime series, converting to empty string
|
Also reproduced on 1.3.4 |
same here on latest 1.4.2, pd.fillna('') doesn't work with NaT (pd.isnull() gives True though) pd.fillna('something') works... Very surpising it has been here since 2016 ? |
same on version 1.4.3, |
same here, NaT still shows if fill na with empty string |
The core issue here appears to be specifically because the Timestamp constructor interprets empty string as
If the behavior of |
This might be the temporary measure 👍
|
I'm a novice, but it seems to still be present in 2.0.1 |
still present |
There is also a bug when replacing with the string
|
|
in contrast, filling on |
So for some reason this worked: literally without the second fillna its not working but with all three its working |
pandas generally tries to coerce values to fit the column dtype, or upcasts the dtype to fit.
For a setting operation this is convenient & I think expected as a user
However for a
.fillna
(or.replace
) operation this might be a bit unexpected. SoA
was coerced toobject
dtype, even though it wasdatetime64[ns]
.So a possibility is to add a keyword
errors='raise'|'coerce'|'ignore'
. This last behavior would be equiv oferrors='coerce'
. While skipping this column would be done witherrors='coerce'
. (and of courseraise
would raise.Ideally would have a default of
coerce
I think (to skip for non-compat values). Any thoughts on this?The text was updated successfully, but these errors were encountered: