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.17:57:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1424887029.92.0.476172755615.issue23517@psf.upfronthosting.co.za>
In-reply-to
Content
> 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 floating point arithmetics, but when converting from nanoseconds to microseconds, you should round to nearest 1000 ns with 500 ns ties resolved to even number of microseconds.


> - os.utime()

This takes nanoseconds as an optional argument.  Passing floats in times should probably be deprecated. In any case, here you would be rounding floats to nanoseconds and what you do with 0.5 nanoseconds is less important because in most cases they are not even representable as floats.

> - time.clock_settime()

Is this a new method?  I don't see it in 3.5.0a1.

> - time.gmtime()

This should be fixed

>>> time.gmtime(1.999999999).tm_sec
1

is really bad and

>>> time.gmtime(-1.999999999)[:6]
(1969, 12, 31, 23, 59, 59)

is probably even worse. 


> - time.localtime()
> - time.ctime()

Same story as in time.gmtime.
History
Date User Action Args
2015-02-25 17:57:09belopolskysetrecipients: + belopolsky, mark.dickinson, vstinner, r.david.murray, ethan.furman, tbarbugli
2015-02-25 17:57:09belopolskysetmessageid: <1424887029.92.0.476172755615.issue23517@psf.upfronthosting.co.za>
2015-02-25 17:57:09belopolskylinkissue23517 messages
2015-02-25 17:57:09belopolskycreate