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() has poor resolution, and we just happened to call today() right before a resolution quantum boundary.
  4. The system clock got fiddled between calls.

The test should be able to address 1 and 4 (unless the clock fiddler is really fast).  2 seems common (I couldn't get the same value twice here), but the timedelta is less than half second, so the test still passes.
So the failure is caused by either 3 (the platform time() has a resolution of more than half second), or by a really slow buildbot, so that half second passes between the two calls, or possibly by a combination of the two.

The attached patch does 3 things:
  1) it uses assertLess instead of assertTrue to get a better error message;
  2) it imports time() directly instead of using time.time(), in order to reduce the delay between the call to .today() and the one to time();
  3) it removes the sleep altogether, since it's useless for cases 1, 2, and 4, and probably doesn't help for case 3 either;

This wouldn't probably fix the sporadic failure, but will give us more information on the next failure and make the tests faster.
Checking the time() resolution on the "x86 OpenIndiana 3.2" might also be useful.

FTR I tried to reproduce the failure using on my machine:
  ./python -m test -m TestSubclassDateTime_Fast -F test_datetime
but I didn't manage to.