Skip to content

TST: Parse dates with empty space (#6428) #14862

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

Merged
merged 2 commits into from
Dec 14, 2016

Conversation

mroeschke
Copy link
Member

Parsing a date with an empty space no longer returns today's date on master 0.19.1. Not sure when this was fixed, but it doesn't seem like it occurred recently.

@codecov-io
Copy link

codecov-io commented Dec 12, 2016

Current coverage is 85.30% (diff: 100%)

Merging #14862 into master will not change coverage

@@             master     #14862   diff @@
==========================================
  Files           144        144          
  Lines         50957      50957          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits          43469      43469          
  Misses         7488       7488          
  Partials          0          0          

Powered by Codecov. Last update 86233e1...36bc9b7

def test_to_datetime_with_space_in_series(self):
# GH 6428
s = Series(['10/18/2006', '10/18/2008', ' '])
tm.assertRaises(ValueError, lambda: to_datetime(s, errors='raise'))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is right

# GH 6428
data = """case,opdate
7,10/18/2006
7,10/18/2008
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should actually parse as datetime and make the space a NaT. So this 'works' in that it doesn't convert as today's date, but it is not registering as missing here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently it looks like errors='ignore' is set when parsing datetimes with read_csv (example). I can change this to errors='coerce'

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, I think we did that on purpose..

that whole clause is bogus, errors='ignore' means it will never raise.

but its a bit tricky, you want to try to parse, then fallback on a softer-parse if necessary.

try playing around with this and see what happens.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah thanks for the insight. I'll tinker with it later tonight.

Copy link
Member Author

@mroeschke mroeschke Dec 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You were correct; current tests require errors='ignore'.

This is tricky since errors='ignore' and errors='coerce' both terminate the parse with NaTs or returning the input. Would it be possible to introduce a new kwarg (e.g. date_errors) to pass ignore/coerce/raise, into to_datetime within read_csv? It could default to ignore.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be possible to introduce a new kwarg (e.g. date_errors) to pass ignore/coerce/raise, into to_datetime within read_csv? It could default to ignore.

This would make the API even more complicated. Generally supporting non-standard datetime parsing should simply use pd.to_datetime post-read_csv.

@jorisvandenbossche any thoughts here.

Copy link
Member Author

@mroeschke mroeschke Dec 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point.

I could clarify in the docs that if parse_dates cannot parse a date the column is returned untouched (which seems like the current behavior) and the user can coerce a space or any unparseable date to NaT post-read_csv with to_datetime

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah that's prob the best soln here (pls add to doc-string & a small warning/note section in io.rst if you don't mind).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, I agree that we should not add kwargs to read_csv for something like this. If you want the date parser, your dates should just be able to be parsed with the default settings, otherwise you can just use to_datetime. PR for doc clarification certainly welcome!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR for doc clarification certainly welcome!

which you already included here :-)

@jreback jreback added Bug IO CSV read_csv, to_csv Testing pandas testing functions or related to the test suite labels Dec 12, 2016
Add doc explaining parse_date limitation
@jorisvandenbossche jorisvandenbossche merged commit 510dd67 into pandas-dev:master Dec 14, 2016
@jorisvandenbossche
Copy link
Member

@mroeschke Thanks!

ischurov pushed a commit to ischurov/pandas that referenced this pull request Dec 19, 2016
@mroeschke mroeschke deleted the test_6428 branch December 21, 2016 04:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug IO CSV read_csv, to_csv Testing pandas testing functions or related to the test suite
Projects
None yet
Development

Successfully merging this pull request may close these issues.

spaces converted to todays date with to_datetime and read_csv date parse
4 participants