Okay, that makes sense. I'm guessing it doesn't actually raise an internal exception. Instead, I see it either (1) causing an integer overflow, or (2) internally coercing the delay to an unsigned 32-bit int value. If (1) is the case, then I'm really passing a negative value for the delay. If it's (2), then something like delay >>> 0 happens, so the delay passed is zero. Either way, the fact that the delay is stored as a 32-bit unsigned int explains this behavior. Thanks!
–
Matt BallAug 12 '10 at 15:22

Old update, but i've just found the max limit is 49999861776383 (49999861776384 causes the callback to fire instantly)
–
maxpJan 9 '14 at 15:03

Timeout values too big to fit into a signed 32-bit integer may cause
overflow in FF, Safari, and Chrome, resulting in the timeout being
scheduled immediately. It makes more sense simply not to schedule these
timeouts, since 24.8 days is beyond a reasonable expectation for the
browser to stay open.

warpech's answer makes a lot of sense - a long running process like a Node.JS server might sound like an exception, but to be honest if you've got something that you want to ensure happens in exactly 24 and a bit days with millisecond accuracy then you should use something more robust in the face of server and machine errors than setTimeout...
–
cfogelbergFeb 9 '14 at 12:07

This is incorrect: Number.MAX_VALUE is an integer. It is the integer 17976931348623157 with 292 zeros after. The reason parseInt returns 1 is because it first converts its argument to a string and then searches the string from left to right. As soon as it finds the . (which isn't a number), it stops.
–
PauanJul 28 '14 at 11:01

By the way, if you want to test if something is an integer, use the ES6 function Number.isInteger(foo). But since it's not supported yet, you can use Math.round(foo) === foo instead.
–
PauanFeb 6 at 0:02