Message250968
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 :-) |
|
Date |
User |
Action |
Args |
2015-09-18 11:57:17 | vstinner | set | recipients:
+ vstinner, paul.moore, belopolsky, tim.golden, python-dev, zach.ware, steve.dower, vmurashev, josh.r |
2015-09-18 11:57:17 | vstinner | set | messageid: <1442577437.41.0.415927201498.issue25155@psf.upfronthosting.co.za> |
2015-09-18 11:57:17 | vstinner | link | issue25155 messages |
2015-09-18 11:57:16 | vstinner | create | |
|