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 josh.r
Recipients belopolsky, josh.r, paul.moore, steve.dower, tim.golden, vmurashev, vstinner, zach.ware
Date 2015-09-17.23:36:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1442532962.94.0.65758106324.issue25155@psf.upfronthosting.co.za>
In-reply-to
Content
It looks like between 3.4.3 and 3.5, datetime_best_possible changed from using _PyTime_gettimeofday with a _PyTime_timeval to using _PyTime_AsTimeval with struct timeval. The difference is that _PyTime_timeval appears to have been defined with a proper time_t for secs, where struct timeval is defined (on Windows) with a long which is still 32 bits on Windows, so we reintroduced the Y2K38 problem.

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
History
Date User Action Args
2015-09-17 23:36:03josh.rsetrecipients: + josh.r, paul.moore, belopolsky, vstinner, tim.golden, zach.ware, steve.dower, vmurashev
2015-09-17 23:36:02josh.rsetmessageid: <1442532962.94.0.65758106324.issue25155@psf.upfronthosting.co.za>
2015-09-17 23:36:02josh.rlinkissue25155 messages
2015-09-17 23:36:02josh.rcreate