Martin v. Löwis added the comment: Tim,
> First, if *both* timestamps went through this code, it's monotonically > non-decreasing. ts1 < ts2 [...] but T(ts1) > T(ts2) can't happen It's as Steve says (and I tried to say before): What *can* happen is that ts1 > T(ts2). ts1 is used by Windows itself as the file stamp when the file is created, as the first .touch() call doesn't set the timestamp (it doesn't call os.utime()). Only ts2 goes through the pygettimeofday. For my original example, we have ts1 = ts2 = 1385154213.291315800, T(ts2) = 1385154213.291315076. Converting this back to a FILETIME gives 1385154213.291315000. > Anyone know the precision of NTFS file creation time? See for example http://doxygen.reactos.org/d8/d55/drivers_2filesystems_2ext2_2src_2write_8c_source.html#l00525 It's only ReactOS, and only the ext2 driver, but I believe the code should be similar for NTFS. The driver does KeQuerySystemTime, and then uses that to set the LastWriteTime. For ext2, there might be truncation, but for NTFS, the value is likely written as-is. So the question is really in which granularity the system time advances. I believe this is still a global variable, updated by the timer interrupt. ---------- _______________________________________ 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
