I guess thats why he mentioned gameservers specifically, as those often depend on being a single node
Node.js devs more than anybody else realize what's wrong with the general direction of mainstream webdev languages, while at the same time cultivating that culture around themselves like that.
A good decision they made was not using high level IO abstractions that both eats performance, and obscures synchronicity implications.
And the bad one is their general chabuduo attitude. While nobody in a sane mind will use node.js for an airplane autopilot,or a space mission software, there is no reason for them not to strive for improving node.js reliability to the extend demanded in the "serious software" industry
The Nightscout artificial pancreas system runs Node.js.
With this bug, glucose monitor readings would stop being delivered after 25 days.
That means it's ok up to 2^53 milliseconds, at which point it starts losing precision (you can't represent every integer above 2^53 as a double, it gets rounded).
It doesn't really matter because no computer that exists today will still be running in 2^53 milliseconds.
i actually came to this bug couple times (nw.js user here)
i re-initialize timers once in a week. :/
A freshman learns not to store data in floating point data types if the significant digits of the data's domain exceeds the floating points guaranteed 1:1 domain.
Some maintainers of node.js's file system module did not (or did not care about it).
Given that JS developers are hailed as the pinnacle of software engineering, this strikes me as odd.
 "But JS does not have a proper 64 bit datatype / BigInts" ... that's not an argument
If you read the link you could figure that out: ;)
"I used libfaketime to speed things up by a factor of 1000 on a linux server "
Can't think why someone would do that. Such a large number of milliseconds just not practical.
* specifically they could reasonably end up with time steps >= 2^31ms. Even if the design isn’t ideal it should still work
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.
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.
JS committee should consider turning timer values into js native signed double
I don't see how that solves anything, you are just defining a new limit to be broken, which would occur when the timer resolution is next increased if not in practice.
It makes sense that either the actual interval or timeout periods are limited by the underlying types used to store them... but I see no intrinsic reason why cumulative time that setInterval runs need be limited by any underlying type (cumulative running time is not needed to calculate when next to call the interval).
I think that having some uniformity in a zoo of rolloverable values will make life easier to people who don't read the language spec meticulously to the letter.
And yes, by any extend of human imagination, no programming language can justify implemention of a plain periodic timer through (oldTime - nowTime) % interval.
A timer should be a timer, and modern opetating sysyems provide developers with a whole arsenal of high level timer abstractions just for those people to not to write their own hacks.
Also, considering the length of that period, it's most likely that the delay for the function-to-be-called is from a business (and not some technical) requirement. So, a more fitting design would be to set up a delayed job for asynchronously executing long-running or later tasks in the background by a scheduler.
The problem is that the function that returned the current time was overflowing a 32-bit integer, so interval calculations were messed up and setInteval() wouldn't fire.
The fix was simply to change an int to an unsigned int.