[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...
tim.peters at gmail.com
Wed Aug 19 17:31:37 CEST 2015
>> >>> 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)
> 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
> 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.
More information about the Datetime-SIG