Relative times containing years fail when computed from a leap day #155
Comments
I'm getting Feb 28, 2017 – are you using a specific version, or master? |
@idpaterson, 1.5 from PyPi. |
Last week I was thinking we should push a new version... |
+1 just hit this problem today |
I just confirmed that this is fixed in |
@mistercrunch there are a lot of changes in master, so that's probably not going to happen today but I'm glad to hear that it's on your mind, @bear! |
Maybe cherry pick the commit that fixes this and push a hotfix to pypi? |
It |
It must have been an incidental fix; there are no commit messages, comments, or test cases specifically addressing the leap day. A pull request against version 1.5 may be appropriate if anyone affected has time to find and patch the issue. I have been using parsedatetime master in production on an Alfred workflow since Feb 2015 with no problems (primarily using |
I can push a version now if that is needed. |
v2.0 has been released |
@bear saves the day. See you in 4 years! |
|
@schoen I will look at that now |
@schoen , many libs are dropping support for |
When it is February 29 (like today!),
parsedatetime.Calendar().parse("1 year")
raisesValueError: day is out of range for month
(It's trying to find February 29 in the following non-leap year, i.e., February 29, 2017.)
I think this is unexpected behavior because people would expect to be able to specify relative time intervals in terms of years on any day. (For example, we had written code that always computes
parse("1 year")
relative to the present day, and it crashes when run today!)The text was updated successfully, but these errors were encountered: