Martin v. Löwis added the comment: I think I found the problem. In one run, the current time (as reported by time.time()) was
1385154213.291315 On the first touch call (in step 1), the file is not there, and gets its current time internally from the system (not sure which part exactly assigns the time stamp). The resulting nanosecond/dwLowDateTime was 291315800 1303049222 Then, the utime call in step 4 asked to set this to 291315078 1303049214 When reading the timestamp back, I get 291315000 1303049214 So in analysis/interpretation A) the time.time() is apparently 712ns earlier than the system time (plus NTFS needs to round to the next multiple of 100ns) B) when setting the time, the requested nanoseconds isn't exactly representable, so it rounds down 78ns. C) as a consequence, the newer timestamp is 800ns before the old one. ---------- _______________________________________ 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
