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 lemburg
Recipients Arfrever, belopolsky, goshawk, lemburg, r.david.murray, vstinner
Date 2012-07-25.11:45:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <500FDC3F.8000501@egenix.com>
In-reply-to <500FDB2D.7040302@egenix.com>
Content
Marc-Andre Lemburg wrote:
> 
>> Alexander Belopolsky <alexander.belopolsky@gmail.com> added the comment:
>>
>> On Wed, Jul 25, 2012 at 4:17 AM, Marc-Andre Lemburg <report@bugs.python.org> wrote:
>>> ... full C double precision for the time part of a timestamp,
>>> which covers nanoseconds just fine.
>>
>> No, it does not:
>>
>>>>> import time
>>>>> t = time.time()
>>>>> t + 5e-9 == t
>> True
>>
>> In fact, C double precision is barely enough to cover microseconds:
>>
>>>>> t + 1e-6 == t
>> False
>>
>>>>> t + 1e-7 == t
>> True
> 
> I was referring to the use of a C double to store the time part
> in mxDateTime. mxDateTime uses the C double to store the number of
> seconds since midnight, so you don't run into the Unix ticks value
> range problem you showcased above.

There's enough room to even store 1/100th of a nanosecond, which may
be needed for some physics experiments :-)

False
>>> x == x + 1e-10
False
>>> x == x + 1e-11
False
>>> x == x + 1e-12
True
History
Date User Action Args
2012-07-25 11:45:09lemburgsetrecipients: + lemburg, belopolsky, vstinner, Arfrever, r.david.murray, goshawk
2012-07-25 11:45:08lemburglinkissue15443 messages
2012-07-25 11:45:08lemburgcreate