osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review


>> > $ stat test | \grep Modify
>> > Modify: 2012-02-16 13:51:25.643597139 +0100
>> > $ stat test2 | \grep Modify
>> > Modify: 2012-02-16 13:51:25.643597126 +0100
>>
>> The loss of precision is not constant: it depends on the timestamp value.
>
> Well, I've tried several times and I can't reproduce a 1 ms difference.
>
>> The loss of precision is between 1 ms and 4 us.
>
> It still looks fishy to me. IEEE doubles have a 52-bit mantissa. Since
> the integral part of a timestamp takes 32 bits or less, there are still
> 20 bits left for the fractional part: which allows for at least a 1 ?s
> precision (2**20 ~= 10**6). A 1 ms precision loss looks like a bug.

Oh... It was a important bug in my function used to change the
denominator of a timestamp. I tried to workaround integer overflow,
but I added a bug. I changed my patch to use PyLong which has no
integer overflow issue.

Fixed example:

>>> open("test", "x").close()
>>> import shutil
>>> shutil.copy2("test", "test2")
[94386 refs]
>>> print(os.stat("test", datetime.datetime).st_mtime)
2012-02-16 21:58:30.835062+00:00
>>> print(os.stat("test2", datetime.datetime).st_mtime)
2012-02-16 21:58:30.835062+00:00
>>> print(os.stat("test", decimal.Decimal).st_mtime)
1329429510.835061686
>>> print(os.stat("test2", decimal.Decimal).st_mtime)
1329429510.835061789
>>> os.stat("test2", decimal.Decimal).st_mtime - os.stat("test", decimal.Decimal).st_mtime
Decimal('1.03E-7')

So the difference is only 0.1 us (100 ns).

It doesn't change anything to the Makefile issue, if timestamps are
different in a single nanosecond, they are seen as different by make
(by another program comparing the timestamp of two files using
nanosecond precision).

Victor