Message290688
| Author |
m-parry |
| Recipients |
m-parry, vstinner |
| Date |
2017年03月28日.08:17:33 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1490689054.3.0.765012771681.issue29921@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
From my opening comment (with new emphasis):
"I think it's the case that **some routes via the C API** now reject out of range values that were previously permitted."
The pywin32 repro I gave above eventually calls PyDateTimeAPI->DateTime_FromDateAndTime():
http://pywin32.hg.sourceforge.net/hgweb/pywin32/pywin32/file/85c1c99b1cb8/win32/src/PyTime.cpp#l980
AFAICT, under Python < 3.6.1 such out of range values were tolerated there. Under Python 2.7, for example, the datetime that results from this call is somewhere in 1899.
I am not claiming that these invalid values should be tolerated forever more, or that this was ever the correct behaviour, but I would have expected a backwards incompatible change like this to happen in, say, Python 3.7, rather than a maintenance release. (Particularly when it breaks a library that's practically standard on Windows.) |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2017年03月28日 08:17:34 | m-parry | set | recipients:
+ m-parry, vstinner |
| 2017年03月28日 08:17:34 | m-parry | set | messageid: <1490689054.3.0.765012771681.issue29921@psf.upfronthosting.co.za> |
| 2017年03月28日 08:17:34 | m-parry | link | issue29921 messages |
| 2017年03月28日 08:17:33 | m-parry | create |
|