[issue13674] crash in datetime.strftime

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 http://hg.python.org/cpython/rev/49db4851c63b

[issue13674] crash in datetime.strftime

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.

[issue13674] crash in datetime.strftime

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 strf

[issue13674] crash in datetime.strftime

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 s

[issue13674] crash in datetime.strftime

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 l

[issue13674] crash in datetime.strftime

Tim Golden added the comment: Attached is a patch with tests -- keywords: +patch Added file: http://bugs.python.org/file32516/issue13674.diff ___ Python tracker ___ _

[issue13674] crash in datetime.strftime

Changes by Tim Golden : -- components: +Windows versions: +Python 3.4 -Python 3.2 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue13674] crash in datetime.strftime

Changes by Tim Golden : -- assignee: -> tim.golden ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue13674] crash in datetime.strftime

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 shoutin

[issue13674] crash in datetime.strftime

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 cod

[issue13674] crash in datetime.strftime

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. > > -

[issue13674] crash in datetime.strftime

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

[issue13674] crash in datetime.strftime

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 cr

[issue13674] crash in datetime.strftime

Tim Golden 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. -- __

[issue13674] crash in datetime.strftime

patrick vrijlandt 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 PythonWin' for further copyright in

[issue13674] crash in datetime.strftime

Tim Golden 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 was that Windows can h

[issue13674] crash in datetime.strftime

patrick vrijlandt added the comment: Is it relevant that 2.7.2 _does_ throw a correct exception? -- ___ Python tracker ___ ___ Python

[issue13674] crash in datetime.strftime

Tim Golden 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 ___ ___

[issue13674] crash in datetime.strftime

STINNER Victor 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 [1; ]"); return

[issue13674] crash in datetime.strftime

Tim Golden 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

[issue13674] crash in datetime.strftime

Tim Golden 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 reproduce the error:

[issue13674] crash in datetime.strftime

Changes by Florent Xicluna : -- nosy: +belopolsky, flox, haypo versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-list maili

[issue13674] crash in datetime.strftime

maniram maniram 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 datetime.strftime should hand

[issue13674] crash in datetime.strftime

New submission from patrick vrijlandt : This causes a crash in python 3.2.2 and 3.2, but not in 2.7.2 C:\Python32>python 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. >>> import datetime