Repository navigation
strptime() can produce invalid date with negative year day #67906
Description
| BPO | 23718 |
|---|---|
| Nosy | @malemburg, @abalkin, @serhiy-storchaka |
| Files |
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:
assignee = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2016-03-12.08:55:19.765>
created_at = <Date 2015-03-20.11:30:32.291>
labels = ['type-bug', 'library']
title = 'strptime() can produce invalid date with negative year day'
updated_at = <Date 2016-03-12.08:55:19.764>
user = 'https://github.com/serhiy-storchaka'bugs.python.org fields:
activity = <Date 2016-03-12.08:55:19.764>
actor = 'serhiy.storchaka'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2016-03-12.08:55:19.765>
closer = 'serhiy.storchaka'
components = ['Library (Lib)']
creation = <Date 2015-03-20.11:30:32.291>
creator = 'serhiy.storchaka'
dependencies = []
files = ['41877', '41936']
hgrepos = []
issue_num = 23718
keywords = ['patch']
message_count = 10.0
messages = ['238648', '259752', '259956', '260168', '260351', '260353', '260360', '261238', '261642', '261643']
nosy_count = 6.0
nosy_names = ['lemburg', 'belopolsky', 'python-dev', 'serhiy.storchaka', 'beng94', 'iaslan']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue23718'
versions = ['Python 2.7', 'Python 3.5', 'Python 3.6']
Activity
serhiy-storchaka commentedon Mar 20, 2015
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.
beng94 commentedon Feb 6, 2016
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.
beng94 commentedon Feb 9, 2016
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.
serhiy-storchaka commentedon Feb 12, 2016
Could you please add tests?
beng94 commentedon Feb 16, 2016
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
serhiy-storchaka commentedon Feb 16, 2016
Could you provide a patch? See also my comment on Rietveld (the "review" link).
beng94 commentedon Feb 16, 2016
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.
serhiy-storchaka commentedon Mar 6, 2016
LGTM. Alexander, what would you say?
python-dev commentedon Mar 12, 2016
New changeset f03da87a79fa by Serhiy Storchaka in branch '3.5':
Issue bpo-23718: Fixed parsing time in week 0 before Jan 1. Original patch by
https://hg.python.org/cpython/rev/f03da87a79fa
New changeset 4fb167ec3108 by Serhiy Storchaka in branch '2.7':
Issue bpo-23718: Fixed parsing time in week 0 before Jan 1. Original patch by
https://hg.python.org/cpython/rev/4fb167ec3108
New changeset a7093386efaf by Serhiy Storchaka in branch 'default':
Issue bpo-23718: Fixed parsing time in week 0 before Jan 1. Original patch by
https://hg.python.org/cpython/rev/a7093386efaf
serhiy-storchaka commentedon Mar 12, 2016
Thank you Tamás for your contribution.