Roundup Robot added the comment:
New changeset 1537f14cc690 by Tim Golden in branch '3.3':
Issue13674 Correct crash with strftime %y format under Windows
http://hg.python.org/cpython/rev/1537f14cc690
New changeset 41a4c55db7f2 by Tim Golden in branch 'default':
Issue13674 Correct crash with
Tim Golden added the comment:
I've committed the changes with a variant of the pre-1900 test running on all
platforms. I think there's scope for more testing of the boundary conditions of
strftime but that would be for another issue. I want to get this one in now as
it's a crasher on Windows.
Roundup Robot added the comment:
New changeset c61147d66843 by Tim Golden in branch 'default':
Issue #13674 Updated NEWS
http://hg.python.org/cpython/rev/c61147d66843
New changeset 49db4851c63b by Tim Golden in branch '3.3':
Issue #13674 Updated NEWS
Changes by Tim Golden m...@timgolden.me.uk:
--
assignee: - tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13674
___
___
Changes by Tim Golden m...@timgolden.me.uk:
--
components: +Windows
versions: +Python 3.4 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13674
___
Tim Golden added the comment:
Attached is a patch with tests
--
keywords: +patch
Added file: http://bugs.python.org/file32516/issue13674.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13674
STINNER Victor added the comment:
+if (strchr(y, outbuf[1]) buf.tm_year 0)
hum... why not simply outbuf[1] == 'y' ? It would be more explicit and less
surprising.
For the unit test, it would be nice to test also asctime(), even if
time.asctime() doesn't use asctime() of the C
Tim Golden added the comment:
On 06/11/2013 15:23, STINNER Victor wrote:
+if (strchr(y, outbuf[1]) buf.tm_year 0)
hum... why not simply outbuf[1] == 'y' ? It would be more explicit
and less surprising.
Ummm. I have no idea what I was thinking about there. I think it was
somehow
gladman added the comment:
On IDLE this:
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit
(AMD64)] on win32
Type copyright, credits or license() for more information.
from datetime import datetime
datetime(1878, 12, 31).strftime('%d %b %y')
causes a crash on
STINNER Victor added the comment:
I am surprised that this bug still exists as it is not far off two years old
now.
You should report the bug to Microsoft who distributes a buggy C runtime
library.
--
___
Python tracker rep...@bugs.python.org
gladman added the comment:
On 30/09/2013 12:39, STINNER Victor wrote:
STINNER Victor added the comment:
I am surprised that this bug still exists as it is not far off two years old
now.
You should report the bug to Microsoft who distributes a buggy C runtime
library.
--
Tim Golden added the comment:
In reality (as I'm sure you can guess) it's just that no-one's got to
the point of fixing it. I did start off, but it's not a trivial fix and
clearly it got sidelined (with no-one shouting). Sometimes that's just
the way it is.
I'll see if I can dig out whatever
gladman added the comment:
On 30/09/2013 13:14, Tim Golden wrote:
Tim Golden added the comment:
In reality (as I'm sure you can guess) it's just that no-one's got to
the point of fixing it. I did start off, but it's not a trivial fix and
clearly it got sidelined (with no-one shouting).
Tim Golden m...@timgolden.me.uk added the comment:
Well, the code in 2.x is quite different from that in 3.x.
Specifically, the 2.x code assumes that, for Windows, no
year before 1900 is valid for any of the formats. So a
simple check throws a ValueError for tm_year 0. For 3.x
the assumption
patrick vrijlandt patrick.vrijla...@gmail.com added the comment:
Somewhere in the code is also/still a seperate check concerning strftime:
PythonWin 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32.
Portions Copyright 1994-2008 Mark Hammond - see 'Help/About
Tim Golden m...@timgolden.me.uk added the comment:
Yes, sorry. I wasn't clear enough. There *are* still checks
in the 3.x code (for the kind of thing you're showing). But
the checks assume 1000 = year = maxint is ok for all format
parameters on Windows. In fact, for %y, only 1900 = year is ok.
New submission from patrick vrijlandt patrick.vrijla...@gmail.com:
This causes a crash in python 3.2.2 and 3.2, but not in 2.7.2
C:\Python32python
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
maniram maniram maniandra...@gmail.com added the comment:
This bug can not be reproduced in Python 3.2.2 on Ubuntu.
Since Python 2.7.2 on your system raises a ValueError for dates below 1900
,your system's strftime probably does not allow dates below 1900 (unlike
Ubuntu).
Python 3.2.2's
Tim Golden m...@timgolden.me.uk added the comment:
Yes, but the MS crt strftime *for %y* requires a year = 1900 (ie
tm_year = 0). Looks like we need a special check.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13674
Changes by Florent Xicluna florent.xicl...@gmail.com:
--
nosy: +belopolsky, flox, haypo
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13674
___
STINNER Victor victor.stin...@haypocalc.com added the comment:
timemodule.c has the following check:
#if defined(_MSC_VER) || defined(sun)
if (buf.tm_year + 1900 1 || buf.tm_year + 1900) {
PyErr_SetString(PyExc_ValueError,
strftime() requires year in
Tim Golden m...@timgolden.me.uk added the comment:
This is happening on Windows x86 against the current tip. The MS C runtime can
handle older dates; it's just that we're taking 1900 off the year at some
point. (At least, I think that's what's happening). FWIW you only need
time.strftime to
Tim Golden m...@timgolden.me.uk added the comment:
... and that's because the tm struct defines the tm_year field as an offset
from 1900. Sorry for the false start. I'll look at the MS runtime stuff instead
--
___
Python tracker
patrick vrijlandt patrick.vrijla...@gmail.com added the comment:
Is it relevant that 2.7.2 _does_ throw a correct exception?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13674
___
24 matches
Mail list logo
