Message246121
| Author |
belopolsky |
| Recipients |
belopolsky, ethan.furman, larry, mark.dickinson, r.david.murray, tbarbugli, trcarden, vstinner |
| Date |
2015年07月03日.02:07:07 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1435889228.66.0.609645465346.issue23517@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Victor> I don't know yet if it should be fixed or not.
It is my understanding that datetime -> timestamp -> datetime round-tripping was exact in 3.3 for datetimes not too far in the future (as of 2015), but now it breaks for datetime(2015, 2, 24, 22, 34, 28, 274000).
This is clearly a regression and should be fixed.
> UNIX doesn't like timestamps in the future
I don't think this is a serious consideration. The problematic scenario would be obtaining high-resolution timestamp (from say time.time()), converting it to datetime and passing it back to OS as a possibly 0.5μs
higher value. Given that timestamp -> datetime -> timestamp roundtrip by
itself takes over 1μs, it is very unlikely that by the time rounded value hits the OS it is still in the future. |
|