What happens when you call setTimeout(fn, 2 ** 31) — a delay of about 25 days — and why?

## The surprise ```js setTimeout(() => console.log('a month from now?'), 2 ** 31); // logs almost immediately ``` A delay that reads as "in about 25 days" behaves as "right now". This is one of the few genuine landmines in the timer API, because it fails in the least safe direction: the callback runs far too early rather than not at all. ## Why 2147483647 Timer delays are stored as a signed 32-bit integer, whose maximum is 2^31 − 1 = 2147483647. In milliseconds that is about 24 days, 20 hours, 31 minutes. Ask for one millisecond more and the value no longer fits; it wraps into the negative range. Negative delays are then clamped to the host minimum — 0 in browsers, 1 in Node — so the timer becomes an immediate one. Node surfaces this rather than hiding it: ``` (node) TimeoutOverflowWarning: 2147483648 does not fit into a 32-bit signed integer. Timeout duration was set to 1. ``` Browsers generally fire without complaint, so in a page the only evidence is the callback running at the wrong time. ## Where it actually bites Nobody writes `2 ** 31` on purpose. The value arrives computed: - `const ms = days * 24 * 60 * 60 * 1000;` with `days` set to 30 by configuration. - `const ms = expiresAt - Date.now();` where `expiresAt` is a far-future timestamp, or where a bad parse made it enormous. - A retry backoff that doubles without a ceiling and eventually crosses the limit. The unit test with a 5-second delay passes; the production config with a 30-day token lifetime fires the "session expired" handler the instant the page loads. The same limit applies to `setInterval`. ## Guarding it The correct posture is to treat any delay you did not literally type as untrusted, and to design around the absolute moment rather than the offset. Two workable shapes: **Re-arm in chunks.** Sleep for at most the maximum, then check whether you have arrived and re-arm if not. ```js const MAX_DELAY = 2147483647; function runAt(deadline, fn) { const remaining = deadline - Date.now(); if (remaining <= 0) return fn(); setTimeout(() => runAt(deadline, fn), Math.min(remaining, MAX_DELAY)); } ``` Note that this also self-corrects: each hop recomputes the remaining time from the clock, so it does not accumulate error, and it re-reads the deadline after the machine has been asleep. **Do not use a timer at all.** For anything measured in days, a long-lived timer is the wrong mechanism regardless of the 32-bit limit: a browser tab will be closed, a page reloaded, a process restarted long before it fires. Store the deadline where it survives — in the record the work belongs to — and check it when something happens. A timer is for "soon"; a timestamp is for "eventually". ## Related clamping, kept straight It is easy to file every timer surprise under one heading. Three distinct rules are at work: - **The upper limit** described here: above ~24.8 days the value overflows and the timer becomes immediate. - **The lower floor:** browsers raise a sub-4 ms delay to 4 ms once a timer chain nests more than five deep; Node raises anything below 1 to 1. - **Throttling:** hidden browser tabs have timers clamped to roughly once per second, and much less often after several minutes in the background. Only the first one makes a timer fire *earlier* than requested; the other two make it later. If you can name which of the three you are looking at from the symptom, you understand the API well enough for any interview that asks.