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.
History
Date User Action Args
2015-07-03 02:07:08belopolskysetrecipients: + belopolsky, mark.dickinson, vstinner, larry, r.david.murray, ethan.furman, tbarbugli, trcarden
2015-07-03 02:07:08belopolskysetmessageid: <1435889228.66.0.609645465346.issue23517@psf.upfronthosting.co.za>
2015-07-03 02:07:08belopolskylinkissue23517 messages
2015-07-03 02:07:08belopolskycreate