3 ms·

Its a feature rather than a bug ;) Can't think why someone would do that. Such a large number of milliseconds just not practical.

olliej 8y ago
Long runtime apps, calendar-esque scheduling, etc al@ seem like things that could reasonably* hit that * specifically they could reasonably end up with time steps >= 2^31ms. Even if the design isn’t ideal it should still work
- avip 8y ago
  That does not sound like a sound implementation.
  - zamalek 8y ago
    The bug occurs if your process reaches ~25 days, period. Regardless of the interval that you set - it could be 1ms and still fail. It has been 'fixed' and is now ~49 days, but setTimeout does not throw and so you have to rely on your process crashing due to some other condition. If you have setTimeout anywhere in your code (including packages), you will need to force it to crash/exit once a month. The implementation of setTimeout in Node is not sound.
  - olliej 8y ago
    It’s perfectly reasonable: Run task every 4 weeks: Onesecond = 1000; Oneminute = 60 * oneSecond; oneHour = 60 * oneMinute; oneDay = 24 * oneHour; oneWeek = 7 * oneDay; Then from that reasonable set of definitions you make a even fire in 4 * oneWeek. Maybe you aren’t even using setTimeout, but you’re using a timer library that internally is just using aetTineout (what does node have besides setTimeout by the way?). You end up with an accumulation of individually reasonable questions that don’t work, for no obvious reason. That said someone else is saying this actually is a “timers stop working in general after X days”, rather than just long lifetime timers, which makes this even more obtuse.
- truth_seeker 8y ago
  IMHO Scheduling the task beyond 12-24 hours, especially when it requires the Runtime timers overhead won't be practical.
Vendan 8y ago
stuff like crons, logging stats, all kinds of things. Note that this apparently even affected some setTimeout calls after that long, so you couldn't schedule something to happen 500 ms from now, for example...
int0x80 8y ago
Either it works or it does not. If it doesn't, you document the fact.
- toast0 8y ago
  If it doesn't work, the attempt to set a timer that won't ever fire should throw as well.
- truth_seeker 8y ago
  I was pointing such large number of milliseconds passed as argument.
  - Vendan 8y ago
    The bug was discovered on a call with 500 passed as the number of milliseconds.
truth_seeker 8y ago
I thank everyone from bottom of my heart who downvoted the comment but know this you will NOT get a gift from Santa this christmas. ;)
- tedunangst 8y ago
  Maybe next time read the bug report. 500 is not an impractically large number of milliseconds.

olliej 8y ago

Long runtime apps, calendar-esque scheduling, etc al@ seem like things that could reasonably* hit that * specifically they could reasonably end up with time steps >= 2^31ms. Even if the design isn’t ideal it should still work

avip 8y ago
That does not sound like a sound implementation.
- zamalek 8y ago
  The bug occurs if your process reaches ~25 days, period. Regardless of the interval that you set - it could be 1ms and still fail. It has been 'fixed' and is now ~49 days, but setTimeout does not throw and so you have to rely on your process crashing due to some other condition. If you have setTimeout anywhere in your code (including packages), you will need to force it to crash/exit once a month. The implementation of setTimeout in Node is not sound.
- olliej 8y ago
  It’s perfectly reasonable: Run task every 4 weeks: Onesecond = 1000; Oneminute = 60 * oneSecond; oneHour = 60 * oneMinute; oneDay = 24 * oneHour; oneWeek = 7 * oneDay; Then from that reasonable set of definitions you make a even fire in 4 * oneWeek. Maybe you aren’t even using setTimeout, but you’re using a timer library that internally is just using aetTineout (what does node have besides setTimeout by the way?). You end up with an accumulation of individually reasonable questions that don’t work, for no obvious reason. That said someone else is saying this actually is a “timers stop working in general after X days”, rather than just long lifetime timers, which makes this even more obtuse.
truth_seeker 8y ago
IMHO Scheduling the task beyond 12-24 hours, especially when it requires the Runtime timers overhead won't be practical.

Vendan 8y ago

stuff like crons, logging stats, all kinds of things. Note that this apparently even affected some setTimeout calls after that long, so you couldn't schedule something to happen 500 ms from now, for example...

int0x80 8y ago

Either it works or it does not. If it doesn't, you document the fact.

toast0 8y ago
If it doesn't work, the attempt to set a timer that won't ever fire should throw as well.
truth_seeker 8y ago
I was pointing such large number of milliseconds passed as argument.
- Vendan 8y ago
  The bug was discovered on a call with 500 passed as the number of milliseconds.

truth_seeker 8y ago

I thank everyone from bottom of my heart who downvoted the comment but know this you will NOT get a gift from Santa this christmas. ;)

tedunangst 8y ago
Maybe next time read the bug report. 500 is not an impractically large number of milliseconds.