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.09:53:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1385200424.17.0.101731806075.issue19715@psf.upfronthosting.co.za>
In-reply-to
Content
Martin, I don't see how:

> What *can* happen is that ts1 > T(ts2)

_in this test_.  As shown in many failure examples *both* nanosecond timestamps had non-zero nanoseconds.  Like:

AssertionError: 1385161652120374900 not greater than or equal to
1385161652120375500

Anything coming from T() would have "000" at the end, not "900" or "500".  T() only retains microseconds.  Or do you disagree with that?

In any case, we're comparing apples to oranges here somehow ;-) If I add:

        p.touch()

right before:

        st = p.stat()
        old_mtime = st.st_mtime
        old_mtime_ns = st.st_mtime_ns

then we're certainly comparing a modification (as opposed to creation) time to a modification time, and I get no more errors.  The nanosecond-difference distribution across 300 runs changed to the obviously bi-modal:

       0: 193
  975800:  12
  975900:   7
  976000:   5
  976100:  29
  976800:  10
  977000:  35
  977100:   9
          ---
          300

I suggest too that's a better way to fix the test than the current

            delta = 1e-6 if os.name == 'nt' else 0

dance.  There's no justification for 1e-6 beyond "well, it seemed to work", and I have shown failure cases with a delta as large as 0.6e-6.
History
Date User Action Args
2013-11-23 09:53:44tim.peterssetrecipients: + tim.peters, loewis, pitrou, tim.golden, jkloth, brian.curtin, python-dev, steve.dower
2013-11-23 09:53:44tim.peterssetmessageid: <1385200424.17.0.101731806075.issue19715@psf.upfronthosting.co.za>
2013-11-23 09:53:44tim.peterslinkissue19715 messages
2013-11-23 09:53:43tim.peterscreate