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
strptime() can produce invalid date with negative year day #67906
Comments
strptime() can produce invalid time with negative year day when parse year-week-weekday set. Such time is rejected by strftime(), so strptime/strftime roundtrip doesn't work. >>> t = time.strptime('2015 0 0', '%Y %U %w')
>>> t
time.struct_time(tm_year=2014, tm_mon=12, tm_mday=28, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=-3, tm_isdst=-1)
>>> time.strftime('%Y %U %w', t)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: day of year out of range |
It looks interesting, let me try to solve this. At first it seems odd that _calc_julian_from_U_or_W returns -2, I guess something is wrong around there. |
I made a patch, that solves this issue. The problem was that there wasn't any Sunday (%w = 0) on the 0th week in 2015. 2015 started on Thursday, therefore the first Sunday was on 2014.12.28. julian variable is used to set the tm_yday, which was a minus value, as the given date was not in the same year. |
Could you please add tests? |
Actually there are already test cases, but they test for the wrong behaviour. The very same example is tested there, but the test gives the expected result, so tm_yday = -3. My implementation returns 362, which looks more reasonable. So currently with my patch the test fails. See the tests here: https://github.com/python/cpython/blob/master/Lib/test/test_strptime.py#L523 |
Could you provide a patch? See also my comment on Rietveld (the "review" link). |
I've added a new patch, it uses an other way to calculate the number of days in a given year. I updated the tests, so now it doesn't fail, I also added some extra test cases to test leap years. |
LGTM. Alexander, what would you say? |
New changeset f03da87a79fa by Serhiy Storchaka in branch '3.5': New changeset 4fb167ec3108 by Serhiy Storchaka in branch '2.7': New changeset a7093386efaf by Serhiy Storchaka in branch 'default': |
Thank you Tamás for your contribution. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: