This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, ethan.furman, mark.dickinson, r.david.murray, tbarbugli, vstinner
Date 2015-02-25.16:48:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1424882926.33.0.512526657044.issue23517@psf.upfronthosting.co.za>
In-reply-to
Content
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 avoid FP timestamps in any case.  On the other hand, double precision timestamps are adequate for microsecond resolution now and in the next few decades.

Timestamps like OP's (sec=1424817268, us=274000) should not change when converted to double and back.  IMO, the following behavior is a bug.

>>> dt = datetime(2015, 2, 24, 22, 34, 28, 274000)
>>> datetime.utcfromtimestamp(dt.timestamp())
datetime.datetime(2015, 2, 25, 3, 34, 28, 273999)
History
Date User Action Args
2015-02-25 16:48:46belopolskysetrecipients: + belopolsky, mark.dickinson, vstinner, r.david.murray, ethan.furman, tbarbugli
2015-02-25 16:48:46belopolskysetmessageid: <1424882926.33.0.512526657044.issue23517@psf.upfronthosting.co.za>
2015-02-25 16:48:46belopolskylinkissue23517 messages
2015-02-25 16:48:46belopolskycreate