[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: Ok, I fixed Python 3.4 and 3.5 too: fromtimestamp() and utcfromtimestamp() now uses also ROUND_HALF_EVEN rounding mode, as timedelta constructor. I explained in Misc/NEWS that the change was made to respect the property: (datetime(1970,1,1) +

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : -- resolution: -> fixed status: open -> closed ___ Python tracker ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset ee1cf1b188d2 by Victor Stinner in branch '3.4': Issue #23517: Fix rounding in fromtimestamp() and utcfromtimestamp() methods https://hg.python.org/cpython/rev/ee1cf1b188d2 -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: Alexander: can you please review attached round_half_even_py34.patch? It's the minimum patch to fix datetime/timedelta rounding for Python 3.4 (and 3.5). -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: Given Victor's reluctance to get this in to 3.5.0, this can't even be marked as a "deferred blocker" anymore. Demoting to normal priority. -- priority: deferred blocker -> normal ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: Given Victor's reluctance to get this in to 3.5.0, this can't even be marked as a "deferred blocker" anymore. Demoting to normal priority. -- priority: deferred blocker -> normal ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Removed file: http://bugs.python.org/file40349/timedelta_round_half_up_py34.patch ___ Python tracker ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: I wish people wouldn't remove old patches. There's no harm in leaving them, and it may be a useful historical record. -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Removed file: http://bugs.python.org/file40362/round_half_up_py34-2.patch ___ Python tracker ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Removed file: http://bugs.python.org/file40365/combined_py34.patch ___ Python tracker ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Removed file: http://bugs.python.org/file40364/fromtimestamp_round_half_up_py34-2.patch ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: I modified Python 3.6 to use ROUND_HALF_EVEN rounding mode in datetime.timedelta, datetime.datetime.fromtimestamp(), datetime.datetime.utcfromtimestamp(). round_half_even_py34.patch: Backport this change to Python 3.4. I tried to write a minimal patch only

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset 171d5590ebc3 by Victor Stinner in branch 'default': Issue #23517: fromtimestamp() and utcfromtimestamp() methods of https://hg.python.org/cpython/rev/171d5590ebc3 -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: > I wish people wouldn't remove old patches. There's no harm in leaving them, > and it may be a useful historical record. It became hard to read this issue, it has a long history. My old patches for Python 3.4 were for ROUND_HALF_UP, but it was then decided

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: Is it appropriate to make this change as a "bug fix", in already-released versions of Python? Would you be happy or sad if you updated your Python from 3.x.y to 3.x.y+1 and the rounding method used when converting floats to datetime stamps changed?

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: Larry> Well, for now I assume it really truly genuinely isn't going in 3.5.0. This is an unfortunate outcome. Larry> I suppose we can debate about 3.4.x and 3.5.1 later It is even more unfortunate that the question of whether this regression is a bug

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: If the guy doing the work says "don't merge it in 3.5.0", and we're at the final release candidate before 3.5.0 final ships, and we don't even have a patch that everyone likes yet... it does seem like it's not going to happen for 3.5.0. Unfortunate perhaps

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: > All you need to do is to revert a few chunks of 1e9cc1a03365 where the > regression was introduced. Hum, please don't revert this change. I spent a lot of days to write pytime.c/.h. My patches add more unit tests to datetime, to test the exact rounding

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: Victor> please don't revert this change. I did not suggest reverting the entire commit. The change that affects fromdatetime() is just -us = round(frac * 1e6) +us = int(frac * 1e6) in datetime.py. It is probably more involved in

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Mark Dickinson added the comment: FWIW, count me as +1 on roundTiesToEven, mostly just for consistency. It's easier to remember that pretty much everything in Python 3 does round-ties-to-even (round function, string formatting, float literal evaluations, int-to-float conversion,

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: Well, for now I assume it really truly genuinely isn't going in 3.5.0. I suppose we can debate about 3.4.x and 3.5.1 later, once we have a fix everybody is happy with. -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: Okay, this is literally the only thing rc3 is waiting on now. -- ___ Python tracker ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: I understand that I have to implement a new rounding mode. The code will be new, I'm not condifent enough to push it immedialty into python 3.5. IMHO a buggy rounding mode is worse than keeping the current rounding mode. The rounding mode changed in python 3.3.

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: I suspect we're not fixing this in 3.4, so I'm removing 3.4 from the version list. -- versions: -Python 3.4 ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: Well, I'm already holding up rc3 on one other issue, might as well fix this too. Can somebody make me a pull request? -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: Universal consensus on ROUND_HALF_EVEN, yes. I would like to see it repaired for 3.5.0, but that's just me saying so without offering to do a single damned thing to make it happen ;-) -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: So is this considered broken enough that I need to accept a fix for 3.5.0? And has a consensus been reached about exactly what that fix would be? -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset d755f75019c8 by Victor Stinner in branch 'default': Issue #23517: Skip a datetime test on Windows https://hg.python.org/cpython/rev/d755f75019c8 -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: Victor, sorry if I muddied the waters here: Alex & I do agree nearest/even must be used. It's documented for timedelta already, and the seconds-from-the-epoch invariant Alex showed is at least as important to preserve as round-tripping. Alex, agreed about the

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: > Alex & I do agree nearest/even must be used. Ok, so Python 3.6 should be updated to use ROUND_HALF_EVEN, and then updated patches should be backported to Python 3.4 and 3.5. Right? Right now, Python 3.6 uses ROUND_HALF_UP. --

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: You may find it easier to start with a patch for 3.5 which is the only time sensitive task. I'll be happy to review your code in whatever form you find it easier to submit, but I believe in hg it is easier to forward port than to backport. --

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: > It doesn't matter who's consuming the rounding of a binary > float to decimal microseconds That is true, but what does matter is who is producing the incoming floats. Consider an extreme case of a timer that ticks twice a microsecond and gives you

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: That's great, Victor! Another person trying the code with their own critical eyes would still be prudent. Two days ago you wrote: > This part of Python (handling timestamps, especially > the rounding mode) is complex, I prefer to check for > all buildbots and

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: I'll try to find the time to kick the tires on this patch this weekend. -- assignee: -> belopolsky ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: Alexander Belopolsky added the comment: > I'll try to find the time to kick the tires on this patch this weekend. Cool! Keep me in touch ;-) -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: Larry, I appreciate the vote of confidence, but I'm ill-equipped to help at the patch level: I'm solely on Windows, and (long story) don't even have a C compiler at the moment. The patch(es) are too broad and delicate to be sure of without kicking the tires

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: 2015-09-04 17:52 GMT+02:00 Tim Peters : > That's great, Victor! Another person trying the code with their own critical > eyes would still be prudent. Sure! > It's not entirely clear why that switched to "So I'm confident on the >

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: > Larry, I appreciate the vote of confidence, but I'm ill-equipped to help at > the patch level: (...) The patch(es) are too broad and delicate to be sure > of without kicking the tires (running contrived examples). Well, the patches change how timedelta,

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by Alexander Belopolsky : -- stage: -> commit review ___ Python tracker ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: Victor, Do I understand correctly that this is already committed in 3.4 - 3.6 development branches and we just need to decide whether to cherry-pick this fix to 3.5rc? Is the "review" link up-to date? --

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: It looks like this patch violates fromtimestamp(s) == EPOCH + timedelta(seconds=s) invariant: Python 3.6.0a0 (default:73911e6c97c8, Sep 4 2015, 13:14:12) >>> E = datetime(1970,1,1,tzinfo=timezone.utc) >>> s = -1/2**7 >>> datetime.fromtimestamp(s,

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: Can someone check 3.3? I believe that was the release where we tried to get various rounding issues right. -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: FYI, that invariant failed for me just now under the released 3.4.3 too: Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: Oh, it looks like my implementation of ROUND_HALF_UP is wrong. Negative numbers are not correctly rounded :-/ I'm working on a fix. -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: Alex, if you like, I'll take the blame for the rounding method - I did express a preference for it here: http://bugs.python.org/issue23517#msg249309 When I looked at the code earlier, the round-half-up implementation looked good to me (floor(x+0.5) if x >= 0

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: > I did not quite understand why you've chosen ROUND_HALF_UP over > ROUND_HALF_EVEN, but as long as fromtimestamp() uses the same rounding as > timedelta() - I am happy. Not only Tim prefers this rounding mode, Python 2.7 also uses the same mode, and the

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Mark Lawrence added the comment: Python 3.3.5 (v3.3.5:62cf4e77f785, Mar 9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import * >>> E = datetime(1970,1,1,tzinfo=timezone.utc) >>> s = -1/2**7 >>>

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: Victor, I did not quite understand why you've chosen ROUND_HALF_UP over ROUND_HALF_EVEN, but as long as fromtimestamp() uses the same rounding as timedelta() - I am happy. -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset 3c29d05c0710 by Victor Stinner in branch 'default': Issue #23517: Fix implementation of the ROUND_HALF_UP rounding mode in https://hg.python.org/cpython/rev/3c29d05c0710 -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: .. and "[Round half to even] is the default rounding mode used in IEEE 754 computing functions and operators." -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: Goodness. It's the properties of "randomly chosen decimals" that have nothing to do with timestamps ;-) timestamps aren't random, so "statistical bias" is roughly meaningless in this context. I gave a specific example before of how nearest/even destroys

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: > Half-up leaves them all 5 microseconds apart, When only looking at the decimal digit in the 6th place after rounding. Which is all I did look at ;-) -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Removed file: http://bugs.python.org/file40363/fromtimestamp_round_half_up_py34-2.patch ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Added file: http://bugs.python.org/file40364/fromtimestamp_round_half_up_py34-2.patch ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: > Is the "review" link up-to date? Oh, I wrote a patch serie, but Rietveld doesn't know the dependencies between my patches... So I attached combined_py34.patch which combines the 3 patches into a single one, hard to reviewer, but it should work with

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: Here is what Wikipedia has to say on the subject: """ Round half to even .. This method treats positive and negative values symmetrically, and is therefore free of sign bias. More importantly, for reasonable distributions of y values, the expected

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: It would be nice to hear from Mark Dickinson on this. In Python 3, we took a much more systematic approach to rounding than a rather haphazard Python 2. For example, the rounding mode for timedelta(0, float_seconds) is not specified in Python 2, but it

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Added file: http://bugs.python.org/file40362/round_half_up_py34-2.patch ___ Python tracker ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Removed file: http://bugs.python.org/file40351/fromtimestamp_round_half_up_py34.patch ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Added file: http://bugs.python.org/file40363/fromtimestamp_round_half_up_py34-2.patch ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Removed file: http://bugs.python.org/file40350/round_half_up_py34.patch ___ Python tracker ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: Yes, it would be good to hear from Mark. When I first saw this report, I checked to see whether he was on the nosy list. He is, but is apparently busy elsewhere. My opinions haven't changed: nearest/even is unnatural for rounding times ("sometimes up,

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: > My opinions haven't changed: nearest/even is unnatural for rounding times > ("sometimes up, sometimes down" grates against the nature of monotonically > non-decreasing timestamps), By the way, why does Python use ROUND_HALF_EVEN for round()? It also feels

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: Victor, there are good "theoretical" reasons for using half/even rounding in _general_ use. But this bug report isn't the place to get into them. Here it just should be enough to note that the IEEE 754 floating point standard _requires_ half/even to be the

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: > By the way, why does Python use ROUND_HALF_EVEN for round()? ROUND_HALF_EVEN does not introduce statistical bias in your floating point data. With this choice a randomly chosen decimal has an equal chance of being rounded up or down. I think one can

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: .. and here is an unbeatable argument: "this variant of the round-to-nearest method is also called unbiased rounding, convergent rounding, statistician's rounding, **Dutch rounding**, Gaussian rounding, odd–even rounding, or bankers' rounding."

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: Ok, thanks for the explanation :-) -- ___ Python tracker ___ ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: > timestamps aren't random, so "statistical bias" is roughly meaningless in > this context. I agree. I don't think I made any arguments about timestamps specifically other than a consistency with timedeltas. In the later case, I think all the usual

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: Bah. It doesn't matter who's consuming the rounding of a binary float to decimal microseconds: there are only 32 possible fractional parts where nearest/even and half-up deliver different results. half-up preserves properties of these specific inputs that

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: I will happy delegate to Tim Peters whether or not this should be fixed in 3.5.0, or whether it should wait until 3.5.1 or even 3.6. Tim, ball's in your court! -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Added file: http://bugs.python.org/file40350/round_half_up_py34.patch ___ Python tracker ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: Backport to Python 3.4 splitted in 3 patches: * (1) timedelta_round_half_up_py34.patch, backport changeset 0eb8c182131e: "datetime.timedelta constructor now rounds microseconds to nearest with ties going away from zero (ROUND_HALF_UP)". * (2)

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by STINNER Victor : Added file: http://bugs.python.org/file40351/fromtimestamp_round_half_up_py34.patch ___ Python tracker ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset bf634dfe076f by Victor Stinner in branch 'default': Issue #23517: fromtimestamp() and utcfromtimestamp() methods of https://hg.python.org/cpython/rev/bf634dfe076f -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: Larry Hasting wrote: >> too late for 3.5.0 > How's that? Well, for example... my change broke all buildbots. I don't think that it's good idea to rush to fix Python 3.5 :-) This part of Python (handling timestamps, especially the rounding mode) is complex, I

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset 30454ef98e81 by Victor Stinner in branch 'default': Backed out changeset b690bf218702 https://hg.python.org/cpython/rev/30454ef98e81 New changeset 700303850cd7 by Victor Stinner in branch 'default': Issue #23517: Fix _PyTime_ObjectToDenominator()

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset 0eb8c182131e by Victor Stinner in branch 'default': Issue #23517: datetime.timedelta constructor now rounds microseconds to nearest https://hg.python.org/cpython/rev/0eb8c182131e -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset 59185ef69166 by Victor Stinner in branch 'default': Issue #23517: test_time, skip a test checking a corner case on floating point https://hg.python.org/cpython/rev/59185ef69166 -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset df074eb2a5be by Victor Stinner in branch 'default': Issue #23517: Try to fix test_time on "x86 Ubuntu Shared 3.x" buildbot https://hg.python.org/cpython/rev/df074eb2a5be -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset abeb625b20c2 by Victor Stinner in branch 'default': Issue #23517: Add "half up" rounding mode to the _PyTime API https://hg.python.org/cpython/rev/abeb625b20c2 -- nosy: +python-dev ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: Ok, I fixed the issue in Python 3.6. Example with the initial message: $ python2.7 -c 'import datetime; print(datetime.datetime.utcfromtimestamp(1424817268.274).microsecond); print(datetime.datetime.utcfromtimestamp(-1424817268.274).microsecond)' 274000

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Larry Hastings added the comment: > too late for 3.5.0 How's that? -- ___ Python tracker ___ ___

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Roundup Robot added the comment: New changeset b690bf218702 by Victor Stinner in branch 'default': Issue #23517: datetime.datetime.fromtimestamp() and https://hg.python.org/cpython/rev/b690bf218702 -- ___ Python tracker

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: IMHO we should only modify the rounding method used by datetime.datetime.fromtimestamp() and datetime.datetime.utcfromtimestamp(), other functions use the right rounding method. Fine by me. How about today? ;-) The regression reported here must get repaired.

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: x = float.fromhex('0x1.38f312b1b36bdp-1') x 0.6112295 round(x, 6) 0.611229 timedelta(0, x).microseconds 611230 but I no longer remember whether we concluded that timedelta got it wrong or round or both or neither. :-) Here you go: import decimal

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- title: datetime.utcfromtimestamp parses timestamps incorrectly - datetime.utcfromtimestamp rounds results incorrectly ___ Python tracker rep...@bugs.python.org

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: I wish we could use the same algorithm in datetime.utcfromtimestamp as we use in float to string conversion. This may allow the following chain of conversions to round trip in most cases: float literal - float - datetime - seconds.microseconds string

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: I wish we could use the same algorithm in datetime.utcfromtimestamp as we use in float to string conversion. This may allow the following chain of conversions to round trip in most cases: float literal - float - datetime - seconds.microseconds string I don't

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: I probably misremembered a different issue. See msg194311. timedelta(seconds=0.6112295) == timedelta(seconds=1)*0.6112295 False I thought the problem there was that the same float was converted to one decimal by str() and to a different decimal by

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Alexander Belopolsky added the comment: OK, I looked at the wrong place. Here is the correct example: x = float.fromhex('0x1.38f312b1b36bdp-1') x 0.6112295 round(x, 6) 0.611229 timedelta(0, x).microseconds 611230 but I no longer remember whether we concluded that timedelta got it wrong or

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

Tim Peters added the comment: Does your algorithm guarantee that any float that is displayed with 6 decimal places or less will convert to a datetime or timedelta with microseconds matching the fractional part? No algorithm can, for datetimes far enough in the future (C doubles just plain

[issue23517] datetime.utcfromtimestamp rounds results incorrectly

STINNER Victor added the comment: Hi, I'm trying to write the rationale of the changes that I wrote in pytime.h in Python 3.3-3.5. The rounding of microseconds or nanoseconds is tricky. The code changed a lot and we used and we are still using various rounding methods depending on the case...