[issue15933] flaky test in test_datetime

Berker Peksag added the comment: The assert was changed (somewhat similar to issue15933.diff) in bc67e8d39164. I've checked last 18 builds (from 800 to 818) on http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.5 and test_today wasn't one of the failed tests. I'm closing this as out

[issue15933] flaky test in test_datetime

Vincent Davis added the comment: Rather than dealing with the time delta how about getting the time twice and checking that we are between and at least once we have the same day. i.e. ts1 = time() today = self.theclass.today() ts2 = time() todayagain1 = self.theclass.fromtimestamp(ts1) todayaga

[issue15933] flaky test in test_datetime

Mark Lawrence added the comment: The patch LGTM, can we have a commit review please. -- nosy: +BreamoreBoy ___ Python tracker ___ ___

[issue15933] flaky test in test_datetime

Changes by Ezio Melotti : -- stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15933] flaky test in test_datetime

Chris Jerdonek added the comment: > That won't always work for case 1 (when theclass is e.g. 'date') and for case > 4 (even if it's unlikely). Can you explain what you mean by this? It seems the timedelta allowance would be equally valid and serve the same purpose no matter what case or wheth

[issue15933] flaky test in test_datetime

Ezio Melotti added the comment: That won't always work for case 1 (when theclass is e.g. 'date') and for case 4 (even if it's unlikely). Technically 2 loops should be enough, but without the sleep I don't think it matters much if it does 1 or 3 loops. -- __

[issue15933] flaky test in test_datetime

Chris Jerdonek added the comment: if today == todayagain: -break +return # test passed Might it make more sense to do the passing time-delta check inside the loop (at the above location), and then raise an exception at the end if the loop exhausts? I think thi

[issue15933] flaky test in test_datetime

Ezio Melotti added the comment: The comment before the check states 4 possible reasons for this failure: 1. It recently became midnight, between the today() and the time() calls. 2. The platform time() has such fine resolution that we'll never get the same value twice. 3. The platform time

[issue15933] flaky test in test_datetime

Chris Jerdonek added the comment: I think we can avoid unnecessary sleeps if we only loop again if the final assert fails (i.e. by including the "or" condition with the time delta allowance inside the loop and not just outside). -- ___ Python tracke

[issue15933] flaky test in test_datetime

Chris Jerdonek added the comment: Here are the 6 cases where it always exhausts on my system: test_today (test.datetimetester.TestSubclassDateTime_Pure) test_today (test.datetimetester.TestDateTimeTZ_Pure) test_today (test.datetimetester.TestDateTime_Pure) test_today (test.datetimetester.TestSub

[issue15933] flaky test in test_datetime

Chris Jerdonek added the comment: I also notice that there is an unnecessary call to time.sleep(0.1) whenever the loop exhausts. This adds .1 seconds to the test run for every call to test_today() on, for example, platforms that "never get the same value twice" (according to the code comment).

[issue15933] flaky test in test_datetime

Brett Cannon added the comment: First off, that assertEquals should have a custom error message stating what values the date objects had to better tell how off things were. Second, this can probably be solved by upping the timedelta to something like a minute or something for when it's run on

[issue15933] flaky test in test_datetime

New submission from Antoine Pitrou: Seen on a buildbot: == FAIL: test_today (test.datetimetester.TestSubclassDateTime_Fast) -- Traceback (most recent call last)