>> > $ 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4