Alexander Belopolsky added the comment:

Victor's motivation for the change was (msg154811):

"""
I chose this rounding method because it is the method used by int(float) and 
int(time.time()) is a common in programs (more than round(time.time()). 
Rounding towards zero avoids also producing timestamps in the future.
"""

I recall the earlier discussions of rounding in the datetime module and Mark's 
explanation that rounding up is fine as long as ordering is preserved. i.e. for 
x < y round(x) <= round(y).

There are cases when producing times in the future are problematic, for example 
UNIX make really dislikes when file timestamps are in the future, but if this 
was the main motivation - rounding towards -infinity would be more appropriate.

In any case, as long as we have the following in the datetime module 
documentation, I think this behavior is a bug:

"""
On the POSIX compliant platforms, utcfromtimestamp(timestamp) is equivalent to 
the following expression:

datetime(1970, 1, 1) + timedelta(seconds=timestamp)
"""

>>> timestamp = 1424817268.274
>>> datetime.utcfromtimestamp(timestamp) == datetime(1970, 1, 1) + 
>>> timedelta(seconds=timestamp)
False

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23517>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to