←back to thread

setBigTimeout

(evanhahn.com)
210 points cfj | 7 comments | | HN request time: 0.95s | source | bottom
1. miiiiiike ◴[] No.41880787[source]
Got hit with this one a few months ago.
replies(2): >>41880846 #>>41880864 #
2. graypegg ◴[] No.41880846[source]
Just out of curiosity, what was the use case for a really long timeout? Feels like most if not all long timeouts would be best served with some sort of "job" you could persist, rather than leaving it in the event queue.
replies(1): >>41881134 #
3. BillyTheKing ◴[] No.41880864[source]
this is the thing with JS and TS - the types and stuff, it's all good until you realise that all integers are basically int 52 (represented as float 64, with 52 bits for the fraction).

Yes, it's nice and flexible - but also introduces some dangerous subtle bugs.

replies(2): >>41881020 #>>41881048 #
4. 8n4vidtmkvmk ◴[] No.41881020[source]
2^53-1 I thought.

And no, they're not all that. There's a bunch that are 2^32 such as this timeout, apparently, plus all the bit shift operations.

5. vhcr ◴[] No.41881048[source]
Not ALL integers are 52 bit, BigInts were added on ECMAScript 2020.
6. cout ◴[] No.41881134[source]
https://thedailywtf.com/articles/The_Harbinger_of_the_Epoch_
replies(1): >>41881210 #
7. graypegg ◴[] No.41881210{3}[source]
To be fair, this will be fixed by browsers when it's within spitting distance of the scale of numbers setTimeout is normally used with. (not huge numbers) Like, if it's close enough that setTimeout(() => {}, 5000) will stop working a month later, that would be a major failure on the browser vendor's part. Much too close for comfort.

But I totally understand it not being a priority if the situation is: setTimeout(() => {}, 500000000) not working in X years.