Changes by Alexandre Conrad alexandre.con...@gmail.com:
--
nosy: +aconrad
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23517
___
___
Tim Peters added the comment:
It is really bad that roundtripping current microsecond datetimes doesn't work.
About half of all microsecond-resolution datetimes fail to roundtrip correctly
now. While the limited precision of a C double guarantees roundtripping of
microsecond datetimes far
Changes by Ethan Furman et...@stoneleaf.us:
--
nosy: -ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23517
___
___
Python-bugs-list
STINNER Victor added the comment:
My rationale is more general than datetime. But problems araise when
different API use different rounding methods.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23517
STINNER Victor added the comment:
Le vendredi 3 juillet 2015, Alexander Belopolsky rep...@bugs.python.org a
écrit :
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
Alexander Belopolsky added the comment:
I'll let others fight this battle. In my view, introducing floating point
timestamp method for datetime objects was a mistake. See issue #2736.
Specifically, I would like to invite Velko Ivanov to rethink his rant at
msg124197.
If anyone followed
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
nosy: -belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23517
___
___
Larry Hastings added the comment:
I'm not going to hold up beta 3 while you guys argue about how to round up or
down the number of angels that can dance on the head of a pin.
--
priority: release blocker - deferred blocker
___
Python tracker
R. David Murray added the comment:
Because this seems to be a regression, I'm marking this as a release blocker.
The RM can decide is isn't, of course.
--
nosy: +larry
priority: normal - release blocker
versions: +Python 3.5, Python 3.6
___
Python
STINNER Victor added the comment:
I'm concerned by this example:
dt = datetime(2015, 2, 24, 22, 34, 28, 274000)
dt - datetime.fromtimestamp(dt.timestamp())
datetime.timedelta(0, 0, 1)
I don't know yet if it should be fixed or not.
If we modify .fromtimestamp(), should we use the same
Alexander Belopolsky added the comment:
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,
Larry Hastings added the comment:
Yes, by all means, fix for 3.4, 3.5, and 3.6. If possible I'd appreciate you
getting the fix checked in to 3.5 within the next 48 hours, as I'm tagging the
next beta release of 3.5 around then, and it'd be nice if this fix went out in
that release.
Timothy Cardenas added the comment:
We are seeing this behavior influencing other libraries in python 3.4.
This should never fail if timestamp and fromtimestamp are implemented correctly:
from datetime import datetime
t = datetime.utcnow().timestamp()
t2 = datetime.utcfromtimestamp(t)
assert t
R. David Murray added the comment:
Most likely this was a rounding fix (ie: not a bug), but hopefully Alexander
will know for sure.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23517
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23517
___
___
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
Alexander Belopolsky added the comment:
Let me dig up the history, but this does not look like correct rounding to me:
datetime.utcfromtimestamp(1424817268.274)
datetime.datetime(2015, 2, 24, 22, 34, 28, 273999)
decimal.Decimal(1424817268.274)
Decimal('1424817268.273294281005859375')
Alexander Belopolsky added the comment:
It looks like it was an intentional change. See #14180 (changeset
75590:1e9cc1a03365).
I am not sure what the motivation was. Note that this change made
utcfromtimestamp(t) different from datetime(1970,1,1) + timedelta(seconds=t).
--
keywords:
Alexander Belopolsky added the comment:
I noticed that the rounding mode of datetime is currently wrong.
What do you mean by currently? What versions of python have it wrong?
--
___
Python tracker rep...@bugs.python.org
STINNER Victor added the comment:
I started a large change set to support nanoseconds in the C pytime API: see
the issue #22117. While working on this change, I noticed that the rounding
mode of datetime is currently wrong. Extract of a private patch:
typedef enum {
/* Round towards zero.
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
keywords: +3.3regression -3.2regression
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23517
___
Alexander Belopolsky added the comment:
For example, in my local patch, I'm using ROUND_FLOOR for:
- datetime.date.fromtimestamp()
- datetime.datetime.fromtimestamp()
These should use ROUND_HALF_EVEN
- datetime.datetime.now()
- datetime.datetime.utcnow()
These should not involve
STINNER Victor added the comment:
What do you mean by currently? What versions of python have it wrong?
I search for ROUND in Modules/_datetimemodule.c: in the Python development
branch (default), I found _PyTime_ROUND_DOWN (Round towards zero). Since a bug
was reported, I understand that
Alexander Belopolsky added the comment:
I don't understand nearest.
Sorry for using loose terms. I was hoping the in the context of going back,
it would be clear.
I believe the correct mode is ROUND_HALF_EVEN. This is the mode used by the
builtin round() function:
round(0.5)
0
Alexander Belopolsky added the comment:
Victor,
Would you consider going back to round to nearest? Mark and I put in a lot of
effort to get the rounding in the datetime module right. (See for example,
#8860.)
Sub-microsecond timesources are still rare and users who work with such should
STINNER Victor added the comment:
Would you consider going back to round to nearest?
I don't understand nearest. I prefer to use names of decimal rounding modes:
https://docs.python.org/dev/library/decimal.html#rounding-modes
In my local patch, I'm using ROUND_FLOOR in _decimal: Round towards
New submission from Tommaso Barbugli:
Hi,
I am porting a library from python 2.7 to 3.4 and I noticed that the behaviour
of datetime.utcfromtimestamp is not consistent between the two versions.
For example on python 2.7.5
datetime.utcfromtimestamp(1424817268.274)
returns a datetime with
Ethan Furman added the comment:
This seems to have changed in 3.3 (versions up to 3.2 return 274000).
--
nosy: +ethan.furman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23517
___
28 matches
Mail list logo
