On 08/18/2015 10:52 PM, Tim Peters wrote:
[Guido]
...
This discussion sounds overly abstract. ISTM that d(x, y) in timeline
arithmetic can be computed as x.timestamp() - y.timestamp(), (and converting
to a timedelta).
As someone else might say, if you want timestamps, use timestamps ;-)
I want to discourage people from thinking of it that way, because it
only works in a theoretical framework abstracting away how arithmetic
actually behaves. Timestamps in Python suck in a world of
floating-point pain that I tried hard to keep entirely out of datetime
module semantics (although I see float operations have increasingly
wormed their way in).
Everyone who thinks about it soon realizes that a datetime simply has
"too many bits" to represent faithfully as a Python float, and so also
as a Python timestamp. But I think few realize this isn't a problem
confined to datetimes only our descendants will experience. It can
surprise people even today. For example, here on my second try:
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. 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.
--
~Ethan~
_______________________________________________
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/
