Antoine Pitrou 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
You mean step 3, right? ("date back 10s")
> 291315078 1303049214
>
> When reading the timestamp back, I get
>
> 291315000 1303049214
Ok, but... the problem is that touch() in step 5 should bump back the
timestamp to 1303049222 plus some nanoseconds. Not leave it at
1303049214. The test is written so that the nanoseconds should be
irrelevant.
(note also how far 1385154213 is from 1303049222, but the test is
careful to avoid that)
----------
_______________________________________
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
