You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.
It seems that setTimeout internally uses a signed 32 bit integer to represent the number of milliseconds to "sleep", giving a maximum delay of 2147483647 ms, about 24.9 days. This might seem like a lot, and I'm sure it doesn't pop up as an issue in in-browser Javascript implementations. However, there are a few cron modules in npm that naively use setTimeout and thus break on once-a-month and similar schedules.
As far as I can see, the setTimeout method is only specified in some HTML5 draft (?) and it says nothing there about a maximum delay value or what should be done if it's exceeded. I'd consider it less surprising and more robust to have setTimeout throw an exception than call the callback immediately when the requested delay is impossible...
The text was updated successfully, but these errors were encountered:
Althought "... changed to 1 ms" - is that really correct, maybe just changed? In 0.8.1 it seems like a straight wrap, i.e. setTimeout(something, 50*86400*1000) will result in a callback in not 1ms and not 50 days, but something more like a few hours probably...
It seems that
setTimeout
internally uses a signed 32 bit integer to represent the number of milliseconds to "sleep", giving a maximum delay of 2147483647 ms, about 24.9 days. This might seem like a lot, and I'm sure it doesn't pop up as an issue in in-browser Javascript implementations. However, there are a few cron modules in npm that naively usesetTimeout
and thus break on once-a-month and similar schedules.The bug is in the module in question, for sure, but it would be nice if the documentation in http://nodejs.org/docs/latest/api/timers.html#setTimeout mentioned the constraints.
As far as I can see, the
setTimeout
method is only specified in some HTML5 draft (?) and it says nothing there about a maximum delay value or what should be done if it's exceeded. I'd consider it less surprising and more robust to havesetTimeout
throw an exception than call the callback immediately when the requested delay is impossible...The text was updated successfully, but these errors were encountered: