Hi there.
When I said "4000", that was because of the conversion to microseconds which happens early on.  

I'm not trying to be difficult here Tim, it's just that you've pointed out a problem and I'd like us to have a comprehensive fix.

"unsigned long", I realized, is also not super, because on unix that can be either 32 or 64 bits :)

The reason 24 hour waits work on 2.7 is that the conversion to microseconds is never done, rather it uses a DWORD of milliseconds.  I agree that this is a regression that needs fixing.  Even if there is a theroetical maximum, it should be higher than that :)

My latest suggestion?  Let's just go ahead and use a "double" for the argument in PyCOND_TIMEDWAIT().

We then have two conversion cases:
1) to a DWORD of milliseconds for both windows apis.  Here we should truncate to the max size of a DWORD
2) to the timeval used on pthreads.

for 1, that can be done like:
if (ds*1e3 > (double)DWORD_MAX)
  ms = DWORD_MAX;
else
  ms = (DWORD)(ds*1e3)

for 2, modifying the PyCOND_ADD_MICROSECONDS macro into something like:

#define PyCOND_ADD_MICROSECONDS(tv, ds)
do {
 long oldsec, sec, usec;
 assert(ds >= 0.0);
 // truncate ds into theoretical maximum
 if (ds > (double)long_max)
    ds = (double)long_max; // whatever that may be
 sec = (long)ds;
 usec = (long)((ds - (double)sec) * 1e6))
 oldsec = tv.tv_sec;
 tv.tv_usec += usec;
 tv.tv_sec += sec;
 if (usec >= 1000000) {
   tv.tv_usec -= 1000000;
   tv.tv_sec += 1;
 }
 if (tv.tv_sec < oldsec)
    /* detect overflow */
    tv.sec = max_long;

I'm not super experienced with integer arithmetic like this or the pitfalls of overflow, so this might need some pondering.  Perhaps it is better to do the tv_sec and tv_usec arithmetic in doubles before converting them back.

Does this sound ok?

Let me see if I can cook up an alternative patch.