[issue7150] datetime operations spanning MINYEAR give bad results

Alexander Belopolsky added the comment: Committed in r81566 (trunk), r81568 (py3k), r81569 (release26-maint), r81570 (release31-maint). -- stage: commit review -> committed/rejected status: open -> closed ___ Python tracker

[issue7150] datetime operations spanning MINYEAR give bad results

Mark Dickinson added the comment: As an aside, I dislike the fact that the datetime module uses a C 'int' for date ordinals, and clearly assumes that it'll be at least 32 bits. int could be as small as 16 bits on some systems (small embedded systems?). But that's another issue. --

[issue7150] datetime operations spanning MINYEAR give bad results

Mark Dickinson added the comment: The patch looks good to me. Please apply! -- assignee: mark.dickinson -> belopolsky resolution: -> accepted ___ Python tracker ___ ___

[issue7150] datetime operations spanning MINYEAR give bad results

Mark Dickinson added the comment: I'll take a look at this patch later today. -- assignee: belopolsky -> mark.dickinson ___ Python tracker ___ ___

[issue7150] datetime operations spanning MINYEAR give bad results

Alexander Belopolsky added the comment: I've untabified my last patch and added a NEWS entry. I believe it is ready for commit review. Mark? -- nosy: +mark.dickinson stage: patch review -> commit review Added file: http://bugs.python.org/file17466/issue7150a.diff ___

[issue7150] datetime operations spanning MINYEAR give bad results

Changes by Alexander Belopolsky : -- assignee: -> belopolsky nosy: +belopolsky -Alexander.Belopolsky ___ Python tracker ___ ___ Python

[issue7150] datetime operations spanning MINYEAR give bad results

Alexander Belopolsky added the comment: My patch includes unit tests and I tested it on Mac OS X. Anand, what kind of testing do you have in mind? -- versions: +Python 2.7, Python 3.2, Python 3.3 ___ Python tracker

[issue7150] datetime operations spanning MINYEAR give bad results

Anand B Pillai added the comment: Can someone update this issue ? Is the 2nd patch tested... ? -- ___ Python tracker ___ ___ Python-bu

[issue7150] datetime operations spanning MINYEAR give bad results

Amaury Forgeot d'Arc added the comment: No, because normally distributions do not use debug builds. but that's the reason why tests are needed: they must pass with asserts enabled. -- ___ Python tracker ___

[issue7150] datetime operations spanning MINYEAR give bad results

Alexander Belopolsky added the comment: Aha! My reliance on asserts() was misguided. With the debug build: >>> t0-d2 Assertion failed: (ordinal >= 1), function ord_to_ymd, file /Users/sasha/Work/python-svn/trunk/Modules/datetimemodule.c, line 269. Abort trap Should we reclassify this bug as

[issue7150] datetime operations spanning MINYEAR give bad results

Alexander Belopolsky added the comment: Given assert(*m > 0); assert(*d > 0); at the end of normalize_y_m_d(), it looks like at lest 1 <=*month and 1 <=*day are redundant. A closer look also reveals assert(1 <= *m && *m <= 12); in the middle of normalize_y_m_d().

[issue7150] datetime operations spanning MINYEAR give bad results

Anand B Pillai added the comment: The problem seems to be in the "normalize_date" function in datetimemodule.c. It is checking for a valid year range, but not checking for a valid month or day range. I have a patch which fixes this problem. It checks for month range (1<=m<=12) and day range(1<

[issue7150] datetime operations spanning MINYEAR give bad results

Anand B Pillai added the comment: The issue is present in Python 3.0 and 2.5 as well. Python 2.5.1 (r251:54863, Jul 17 2008, 13:21:31) [GCC 4.3.1 20080708 (Red Hat 4.3.1-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> t0=datetime.date

[issue7150] datetime operations spanning MINYEAR give bad results

New submission from mark.leander : The datetime module documentation would imply that operations that cause dates to fall outside the MINYEAR--MAXYEAR range should raise OverflowError. The interpreter session below shows that this is not always the case, and that such operations may cause bogus a