Skip to content
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

Unexpected result for some dates #5

Open
gakhov opened this issue Feb 11, 2015 · 2 comments
Open

Unexpected result for some dates #5

gakhov opened this issue Feb 11, 2015 · 2 comments

Comments

@gakhov
Copy link

gakhov commented Feb 11, 2015

I use 1.2 version of the parser and receive such response, that i think is inconsistent with others:

from daterangeparser import parse as parse_daterange
parse_daterange("to 5Jul2015")
>> (datetime.datetime(2015, 7, 1, 0, 0), datetime.datetime(2015, 7, 5, 0, 0))

So, it returns correct end_date, but unexpected start_date equals to the start of that month. I expect to have None as the start_date.

For instance, if I parse another the close string, it behaves right (form my point of view):

from daterangeparser import parse as parse_daterange
parse_daterange("from 5Jul2015")
>> (datetime.datetime(2015, 7, 5, 0, 0), None)
@robintw
Copy link
Owner

robintw commented Feb 11, 2015

Thanks for the bug report - I see what you mean.

I've had a bit of a play with code, and it's a bit more complicated to fix than I was hoping... At the moment if it can only find a single date then it just returns it as the start_date with the end_date set to None.

I can easily make it so that

parse_daterange("to 5Jul2015")
>> (datetime.datetime(2015, 7, 5, 0, 0), None)

Would that be suitable for you, or do you really need it to be the other way around? I agree that the other way around would be better, but it will require a fair bit of re-engineering of the code to be able to deal with it.

@gakhov
Copy link
Author

gakhov commented Feb 11, 2015

That's a problem, unfortunately ... I need to store start_date and end_date separately and i don't know in advance if it's to 5Jul2015 or from 5Jul2015 ... The solution with start_date, None could work for me, but it will keep inconsistency in your code .... Probably, make sense to solve such issue in the future with big changes instead of making patch right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants