Message290699
| Author |
m-parry |
| Recipients |
m-parry, vstinner |
| Date |
2017年03月28日.12:23:58 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1490703838.1.0.814733102576.issue29921@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
That's just a Python C API call. It looks like it eventually resolves to new_datetime_ex(30828, 9, 13, 3, 48, 5, 480000, Py_None, PyDateTime_DateTimeType).
We also have some internal code that sees a similar problem from calling PyTime_FromTime(), that was similarly affected by this change. In one example, that appears to resolve to new_time_ex(24, 0, 0, 0, Py_None, PyDateTime_TimeType). Again, under <3.6.1, that was accepted. (And again, I am making no argument about the validity of this code, just with regards to backwards compatibility.) |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2017年03月28日 12:23:58 | m-parry | set | recipients:
+ m-parry, vstinner |
| 2017年03月28日 12:23:58 | m-parry | set | messageid: <1490703838.1.0.814733102576.issue29921@psf.upfronthosting.co.za> |
| 2017年03月28日 12:23:58 | m-parry | link | issue29921 messages |
| 2017年03月28日 12:23:58 | m-parry | create |
|