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

[Guido van Rossum]

On Thu, Feb 16, 2012 at 2:48 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:
> 2012/2/16 Guido van Rossum <guido at python.org>:
>> On Thu, Feb 16, 2012 at 2:04 PM, Victor Stinner
>> <victor.stinner at gmail.com> wrote:
>>> 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).
>>
>> But make doesn't compare timestamps for equality -- it compares for
>> newer. That shouldn't be so critical, since if there is an *actual*
>> causal link between file A and B, the difference in timestamps should
>> always be much larger than 100 ns.
>
> The problem is that shutil.copy2() produces sometimes *older*
> timestamp :-/ As shown in my previous email: in such case, make will
> always rebuild the second file instead of only build it once.
>
> Example with two consecutive runs:
>
> $ ./python diff.py
> 1329432426.650957952
> 1329432426.650958061
> 1.09E-7
>
> $ ./python diff.py
> 1329432427.854957910
> 1329432427.854957819
> -9.1E-8

Have you been able to reproduce this with an actual Makefile? What's
the scenario? I'm thinking of a Makefile like this:

a:
    cp /dev/null a
b: a
    cp a b

Now say a doesn't exist and we run "make b". This will create a and
then b. I can't believe that the difference between the mtimes of a
and b is so small that if you copy the directory containing Makefile,
a and b using a Python tool that reproduces mtimes only with usec
accuracy you'll end up with a directory where a is newer than n.

What am I missing?

-- 
--Guido van Rossum (python.org/~guido)