This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: datetime doesn't check for min/max dates anymore in Python 3.6.0 => crash
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.6
Status: closed Resolution: duplicate
Dependencies: Superseder: datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6
View: 29100
Assigned To: Nosy List: Eli Collins, belopolsky, lemburg, vstinner
Priority: normal Keywords: 3.6regression

Created on 2017-01-22 17:47 by Eli Collins, last changed 2022-04-11 14:58 by admin. This issue is now closed.

File name Uploaded Description Edit Eli Collins, 2017-01-22 17:47
Messages (5)
msg286021 - (view) Author: Eli Collins (Eli Collins) * Date: 2017-01-22 17:47
I've found an odd behavior when passing very large values to ``datetime.datetime.utcfromtimestamp()`` and ``.fromtimestamp()`` under python 3.6.

Under python 3.5, ``utcfromtimestamp(1<<40)`` would throw a ValueError that the year was out of range.  Under python 3.6, this now returns a datetime in year 36812 (which seems reasonable given the input).  

The unexpected behavior occurs when increasing the bits passed:   ``utcfromtimestamp(1<<41)`` returns a datetime with a *smaller* year (6118).  This pattern proceeds as the bits are increased, with the years increasing & then wrapping around again, up to the point where it exceeds time_t (at that point, python 3.6 throws the same OSError as 3.5).

It looks to me like 3.6 dropped a bounds check somewhere, and is now truncating high bits off the resulting year?


Attached is the "" script that I was using to examine boundary behavior of utctimestamp() when I found this bug.

System was running Linux Mint 18.1 x86_64, using the python 3.6.0 build from (ubuntu's python 3.6.0 build also shows this behavior).
msg286025 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2017-01-22 18:52
According to the datetime.h file, the valid range for year is 1-9999, so it's a bit surprising that Python 3.6 allows dates outside this range.

Internally, the year is represented using 2 bytes, so you could represent years outside the range and up to 65535 as well.

Here's what mxDateTime outputs for the given timestamps:

 >>> from mx.DateTime import *
 >>> DateTimeFromTicks(1<<40)
<mx.DateTime.DateTime object for '36812-02-20 01:36:16.00' at 7f17a38a2390>
 >>> DateTimeFromTicks(1<<41)
<mx.DateTime.DateTime object for '71654-04-10 03:12:32.00' at 7f17a1bdf858>
msg286034 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2017-01-22 23:45
This looks like a duplicate of issue #29100 ("datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6").
msg286091 - (view) Author: Eli Collins (Eli Collins) * Date: 2017-01-23 15:16
My apologies, I think Alexander is right, this is a duplicate of #29100

I'd seen the first message in that issue talking about a core dump, and thought this was different problem; but I see the scope of the issue broadened to cover general bounds issues in later messages. 

Reviewing the fix & the tests from that issue's patches, it looks like exactly this case.
msg286360 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-27 14:58
Since it's a duplicate, I close this issue.
Date User Action Args
2022-04-11 14:58:42adminsetgithub: 73532
2017-01-27 14:58:10vstinnersetstatus: open -> closed
superseder: datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6
messages: + msg286360
2017-01-27 14:57:37vstinnersettitle: datetime.utcfromtimestamp() returns strange result for very large values -> datetime doesn't check for min/max dates anymore in Python 3.6.0 => crash
2017-01-23 15:16:59Eli Collinssetresolution: duplicate
messages: + msg286091
2017-01-22 23:45:01belopolskysetkeywords: + 3.6regression
nosy: + vstinner
messages: + msg286034

2017-01-22 18:52:42lemburgsetmessages: + msg286025
2017-01-22 18:24:57serhiy.storchakasetnosy: + lemburg, belopolsky
2017-01-22 17:47:34Eli Collinscreate