You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The input dataframe contains the dt_reference column - which contains date information in the format "%d/%m/%Y" - as a Pandas Object dtype.
When i set the "dt_reference" column format to be of any date (pandas.Timestamp, pandera.dtypes.DateTime or pandera.dtypes.Date), I would expect it to try and coerce the column to my desired dtype. However as it cannot format the date using its default ISO format, it would raise a SchemaErrors. That, combined with the Config "drop_invalid_rows" setted to True, i would expect it to drop all rows, returning an empty dataframe.
This behavior is achieved by the last class (InputMomentumDate), but the previous classes (InputMomentumTimestamp and InputMomentumDateTime) return the validated dataframe without any errors but with the dt_reference column still being Object dtype.
Is this a bug or expected behavior? If expected, could someone explain why this happens?
Thanks
The text was updated successfully, but these errors were encountered:
Code Sample
Expected behavior
The input dataframe contains the dt_reference column - which contains date information in the format "%d/%m/%Y" - as a Pandas Object dtype.
When i set the "dt_reference" column format to be of any date (pandas.Timestamp, pandera.dtypes.DateTime or pandera.dtypes.Date), I would expect it to try and coerce the column to my desired dtype. However as it cannot format the date using its default ISO format, it would raise a SchemaErrors. That, combined with the Config "drop_invalid_rows" setted to True, i would expect it to drop all rows, returning an empty dataframe.
This behavior is achieved by the last class (InputMomentumDate), but the previous classes (InputMomentumTimestamp and InputMomentumDateTime) return the validated dataframe without any errors but with the dt_reference column still being Object dtype.
Is this a bug or expected behavior? If expected, could someone explain why this happens?
Thanks
The text was updated successfully, but these errors were encountered: