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
This is caused because duparse takes the ordinal as a literal date when the previous types aren't satisfied. Since unregistering the datetime converter affects the other fields on the series, the only solution I found is to define a new ordinal type.
So the question to discuss is if the default fallback value should be datetime because the same issue happens when the string contains a ratio like 2/3
The text was updated successfully, but these errors were encountered:
Good observation. Since dateutil (duparse) will try to infer what it can, so there are likely a bunch of other edge cases that could be hit. This may need to be a parameter as to whether date parsing through be fuzzy or strict (i.e. one of the predefined date formats).
When dealing with regular english ordinal numbers, the library converts then to datetime.
ex:
list(strconv.convert_series(["20th", "street", "2015-01-01"]))
becomes:
[datetime.datetime(2017, 7, 20, 0, 0), 'street', datetime.datetime(2015, 1, 1, 0, 0)]
This is caused because duparse takes the ordinal as a literal date when the previous types aren't satisfied. Since unregistering the datetime converter affects the other fields on the series, the only solution I found is to define a new ordinal type.
So the question to discuss is if the default fallback value should be datetime because the same issue happens when the string contains a ratio like
2/3
The text was updated successfully, but these errors were encountered: