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.

Author vstinner
Recipients belopolsky, josh.r, paul.moore, python-dev, steve.dower, tim.golden, vmurashev, vstinner, zach.ware
Date 2015-09-18.11:57:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1442577437.41.0.415927201498.issue25155@psf.upfronthosting.co.za>
In-reply-to
Content
Oh wow, I didn't expect such much headaches when I worked on unifiying the code to handle timestamps in the C part of CPython...

> The bug was introduced while trying to support #22117: "Rewrite pytime.h to work on nanoseconds" in reve93eeadef0c3: https://hg.python.org/cpython/rev/e93eeadef0c3

Yeah, the changeset e93eeadef0c3 was the last change to drop the last function of the old PyTime.

Well... in fact, I also had to keep _PyTime_ObjectToTime_t() and _PyTime_ObjectToTimeval() for the exact same reason: support timestamp after the year 2038 on Windows.

Right, the tv_sec field of a timeval structure on Windows has the C type long, whereas it has the type time_t on all other platforms...

I fixed the bug in Python 3.5 and 3.6. Thanks for your bug report. I didn't expect to test year 2038 bug on the latest release, thanks time traveler :-)
History
Date User Action Args
2015-09-18 11:57:17vstinnersetrecipients: + vstinner, paul.moore, belopolsky, tim.golden, python-dev, zach.ware, steve.dower, vmurashev, josh.r
2015-09-18 11:57:17vstinnersetmessageid: <1442577437.41.0.415927201498.issue25155@psf.upfronthosting.co.za>
2015-09-18 11:57:17vstinnerlinkissue25155 messages
2015-09-18 11:57:16vstinnercreate