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 vstinner
Recipients SilentGhost, belopolsky, lemburg, serhiy.storchaka, vstinner
Date 2015-03-30.11:36:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1427715417.39.0.550309722172.issue23607@psf.upfronthosting.co.za>
In-reply-to
Content
I reviewed datetime_fromtimestamp_decimal.patch.

> As side effect Decimal timestamps now are supported in few other places, e.g. in os.utime().

It would be more consistent to support decimal.Decimal nowhere or "everywhere". IMO the new _PyTime_FromSecondsObject() (very close to _PyTime_ObjectToDenominator, but using time_t) should also be patched.

Please add some tests for decimal.Decimal in test_time directly. Usually, I try to test rounding and overflow. Testing for overflow is not always possible because it may depend on the platform.

--

See also the PEP 410: "PEP 410 - Use decimal.Decimal type for timestamps". The PEP was rejected. The compromise was a new timestamp format for os.utime(): a number of nanoseconds since the UNIX epoch (1970-01-01). I partially implemented a private API for this PEP in the issue #22117: the new _PyTime_t is a number of timestamp using an arbitrary resolution (currently, it's a number of nanoseconds using a 64-bit signed integer type).
History
Date User Action Args
2015-03-30 11:36:57vstinnersetrecipients: + vstinner, lemburg, belopolsky, SilentGhost, serhiy.storchaka
2015-03-30 11:36:57vstinnersetmessageid: <1427715417.39.0.550309722172.issue23607@psf.upfronthosting.co.za>
2015-03-30 11:36:57vstinnerlinkissue23607 messages
2015-03-30 11:36:57vstinnercreate