[Tim] >> ... >> >>> d = datetime.now() >> >>> d >> datetime.datetime(2015, 8, 18, 23, 8, 54, 615774) >> >>> datetime.fromtimestamp(d.timestamp()) >> datetime.datetime(2015, 8, 18, 23, 8, 54, 615773)
[Ethan Furman] > This bug was introduced by Victor Stinner in issue 14180, and is being > tracked in issue 23517. Thanks! I haven't paid much attention for years, and was blissfully unaware of this. Victor's "round by truncation" patch is clearly the cause of this specific roundtrip failure, but because of the fundamental "not enough bits" reality there is no possible way of converting to a C double that won't fail to convert back faithfully _eventually_ (for then-current datetimes obtained in the future, or for future datetimes typed in today). If datetime is extended to support nanoseconds, replace "the future" with "the past" (faithful roundtripping of nanoseconds would require another (approximately) 20 bits in the C double, but microsecond datetimes from 2015 are already near the edge of what can be done with the 53 bits a C double has - even with "better" rounding). > Versions 3.3, 3.4, and soon 3.5 are affected. > Victor is refusing to fix/revert, Alexander has given up arguing with him, > and I lack the necessary skills. > > Perhaps the best path forward is to deprecate `.timestamp()` and friends. There's "a reason" they weren't in the original design ;-) I see there's already tons of discussion on the referenced (& related) bugs reports, so if I have a bright idea I'll put it on those. _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
