New submission from Eli Collins: 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). ---------- components: Library (Lib) files: dump_timestamp_output.py messages: 286021 nosy: Eli Collins priority: normal severity: normal status: open title: datetime.utcfromtimestamp() returns strange result for very large values type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46384/dump_timestamp_output.py _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29346> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
