This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients brian.curtin, jkloth, loewis, pitrou, python-dev, steve.dower, tim.golden, tim.peters
Date 2013-11-23.06:16:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1385187364.63.0.716892504929.issue19715@psf.upfronthosting.co.za>
In-reply-to
Content
Steve, I'm afraid sleeping 100ns wouldn't be enough. The more data I collect, the more bizarre this gets :-(

Across 300 runs I recorded the difference, in nanoseconds, between the "old" and "new" timestamps.  A negative difference is a test failure.  I was very surprised (for one thing) to see how few *distinct* values there were:

    -600:   5
    -500:   9
    -200:   1
    -100:   8
       0:  13
     100:   1
  975800:   7
  975900:  58
  976000:  69
  976100:   7
  976300:   9
  976400:  48
  976500:  52
  976600:   6
 1952400:   1
 1952500:   1
 1952800:   1
 1952900:   3
 1953000:   1
          ---
          300

So the vast bulk of the differences were close to a millisecond (1e6 nanoseconds), and a handful at the tail close to 2 milliseconds.  Anyone know the precision of NTFS file creation time?  I know the time structure is _capable_ of 100ns resolution, but the numbers above strongly suggest the precision is a lot closer to a millisecond.

Anyway, on the failure end, the biggest difference seen was 600 nanoseconds.  A 100ns sleep wouldn't cover that ;-)
History
Date User Action Args
2013-11-23 06:16:04tim.peterssetrecipients: + tim.peters, loewis, pitrou, tim.golden, jkloth, brian.curtin, python-dev, steve.dower
2013-11-23 06:16:04tim.peterssetmessageid: <1385187364.63.0.716892504929.issue19715@psf.upfronthosting.co.za>
2013-11-23 06:16:04tim.peterslinkissue19715 messages
2013-11-23 06:16:04tim.peterscreate