Alexander Belopolsky added the comment:
including Jan 30 - did you mean Dec 31?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
___
Roundup Robot added the comment:
New changeset d9f3dd1d6b48 by Serhiy Storchaka in branch '2.7':
Fixed Misc/NEWS entry for issue #23136.
https://hg.python.org/cpython/rev/d9f3dd1d6b48
New changeset afca9867e1bb by Serhiy Storchaka in branch '3.4':
Fixed Misc/NEWS entry for issue #23136.
Serhiy Storchaka added the comment:
Thank you for the review Alexander. Thank you for your contribution Jim.
--
resolution: - fixed
stage: commit review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 350ea309953e by Serhiy Storchaka in branch '2.7':
Issue #23136: _strptime now uniformly handles all days in week 0, including
https://hg.python.org/cpython/rev/350ea309953e
New changeset 93e1da502338 by Serhiy Storchaka in branch '3.4':
Issue
Serhiy Storchaka added the comment:
Oh, I meant Dec 30.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
___
Python-bugs-list mailing
Serhiy Storchaka added the comment:
Is it possible to fix the commit message without breaking any of cloned
repositories that already have pulled it?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
Alexander Belopolsky added the comment:
I don't think it is worth the effort to try to fix the commit message, but it
would be nice to have the NEWS text corrected.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
Alexander Belopolsky added the comment:
Probably not.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
___
Python-bugs-list mailing list
Jim Carroll added the comment:
Thanks for all your work !
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
___
Python-bugs-list mailing
Alexander Belopolsky added the comment:
Serhiy,
Your latest patch LGTM.
--
stage: patch review - commit review
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file37674/strptime_julian_none_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
Alexander Belopolsky added the comment:
Note that round-trip also fails in weeks 52-53. For example,
datetime.strptime('2014 53 6', '%Y %W %w')
datetime.datetime(2015, 1, 10, 0, 0)
datetime.strptime('2014 53 6', '%Y %W %w').strftime('%Y %W %w')
'2015 01 6'
If we decide to make 2015 0 0
Jim Carroll added the comment:
All the proposed patches are acceptable from my point of view, but it would be
really great if we could get the fix in the 2.x line. It seems unlikely there
could be any legacy code that would depend on the bug to exist (ie: to only be
wrong when then date
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +belopolsky, lemburg
stage: - patch review
versions: +Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
___
Python-bugs-list
Changes by Saimadhav Heblikar saimadhavhebli...@gmail.com:
--
nosy: +sahutd
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
___
Alexander Belopolsky added the comment:
What's a New Year without fixing a calendar bug! :-)
Jim's logic looks right to me. The patch needs a test before it can be applied.
--
___
Python tracker rep...@bugs.python.org
Saimadhav Heblikar added the comment:
Hi,
Here is my understanding of it.
I have used the following C example of strptime and strftime to show that the
string '0 2015 2' along with the format specifier '%W %Y %w' is invalid.
For any valid string, strptime followed by strftime should return
Alexander Belopolsky added the comment:
In a comment for #23134, Serhiy suggested that this may not be a bug
(msg233215) because C strptime behavior for this case is undefined.
I disagree. On Mac OSX, strptime man page states:
The %U and %W format specifiers accept any value within the
Alexander Belopolsky added the comment:
See also #12006.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
___
Python-bugs-list mailing
Serhiy Storchaka added the comment:
Thank you Jim for your patch. That all right and the patch fixes the issue. But
the code looks a little tricky, and it would be more robust to use other
signal value for julian (e.g. None).
However I'm not sure that strptime should accept weekdays before
Changes by Tomasz Ryczkowski tomaszr...@gmail.com:
--
nosy: +torm
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
Here is alternative patch which rejects week-weekday combinations out of
specified year.
--
Added file: http://bugs.python.org/file37575/strptime_check_valid_week.patch
___
Python tracker rep...@bugs.python.org
Jim Carroll added the comment:
I understand. Actually, raising an exception would be perfectly acceptable as
well (possibly even more desirable).
I too experimented with the c-lib strptime() and discovered the negative values
of tm_mday. These results are good too -- as they clearly show the
Alexander Belopolsky added the comment:
For any valid string, strptime followed by strftime should return
the same string.
Not necessarily. String to datetime mapping implemented by strptime can be
many to one. For example,
datetime.strptime(2014 366, %Y %j) == datetime.strptime(2015 1,
Saimadhav Heblikar added the comment:
Not necessarily. String to datetime mapping implemented by strptime can be
many to one. For example,
I was referring to C strptime and strftime.
But thanks for posting the round trip example. I was unaware of it.
--
Alexander Belopolsky added the comment:
I would prefer to accept denormalized %Y %W %w combinations. Note that
while Mac OSX and glibc versions of strptime produce different results, neither
implementation signals an error by returning NULL.
In C the strptime function doesn't return valid
Alexander Belopolsky added the comment:
Also, given that 2015 0 0, 2015 0 1, and 2015 0 3, all currently work
with '%Y %W %w' format specification and produce dates in the year 2014, I
think raising an error in all those cases is more likely to break user code
than correcting the value in
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
nosy: +Erik.Cederstrand, aganders3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23136
___
New submission from Jim Carroll:
The following bit of code demonstrates a bug in how _strptime handles week 0.
The bug is an edge condition that specifically affects how it handles two days
before the first day of the new year
for i in range(7):
... datetime.strptime('%s %s %s' % (0,
30 matches
Mail list logo
