Tim Peters added the comment:
[MvL]
> One "obvious" conversion error is this code from
>
> http://hg.python.org/cpython/file/4101bfaa76fe/Python/pytime.c#l35
>
> microseconds = large.QuadPart / 10 - 11644473600000000;
>
> This discard the 100ns part of the current time, rounding it
> down to the previous microsecond. As a result, the second
> time stamp can be up to a microsecond earlier than the previous
> one.
I don't think so, on two counts. First, if *both* timestamps went through this
code, it's monotonically non-decreasing. That is, if ts1 and ts2 are two
full-precision (100ns resolution) timestamps, and ts1 < ts2, then calling the
transformation above `T` we'll always have T(ts1) <= T(ts2). T(ts1) can be
equal to T(ts2) even if ts1 < ts2, but T(ts1) > T(ts2) can't happen (because
C's unsigned integer division truncates).
Second, the version of the test code that compared .st_mtime_ns members showed
timestamps with 100-ns resolution. Like:
self.assertGreaterEqual(c_mtime_ns, old_mtime_ns)
AssertionError: 1385179768290263800 not greater than or equal to
1385179768290264500
Note the trailing "800" and "500" in those. So it's not possible that those
timestamps came from a _PyTime_timeval (which the code you showed is
constructing) - that struct records no info about nanoseconds.
There's another clue I don't know what to make of: I've seen dozens of these
failures now, and I believe that in every case the original timestamp (the one
that should be older) _always_ ended with "500" (in st_mtime_ns format).
That's true in the example I posted just above, and also true of the 3 examples
I posted in msg203913.
LOL! So much for that clue - while I was typing I got this failure:
AssertionError: 1385181174851605800 not greater than or equal to
1385181174851606000
So the older timestamp in failing cases always ends with "500" or "000" ;-)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19715>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
