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 "dump_timestamp_output.py" 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 https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes (ubuntu's python 3.6.0 build also shows this behavior).

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>

This looks like a duplicate of issue bpo-29100 ("datetime.fromtimestamp() doesn't check min/max year anymore: regression of Python 3.6").

My apologies, I think Alexander is right, this is a duplicate of bpo-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.

Since it's a duplicate, I close this issue.