[yesco]

> In most JavaScript runtimes, this duration is represented as a 32-bit signed integer

I thought all numbers in JavaScript were basically some variation of double precision floating points, if so, why is setTimeout limited to a smaller 32bit signed integer?

If this is true, then if I pass something like "0.5", does it round the number when casting it to an integer? Or does it execute the callback after half a millisecond like you would expect it would?

[arp242]

You're correct about JS numbers. It works like this presumably because the implementation is written in C++ or the like and uses an int32 for this, because "25 days ought to be enough for everyone".

[drdaeman]

I thought most non-abandoned C/C++ projects have long switched to time_t or similar. 2038 is not that far in the future.

[andrewmcwatters]

2038 is even "now" if you're calculating futures.

[afavour]

Yes but JS always has backwards compatibility in mind, even if it wasn’t in the spec. Wouldn’t be surprised if more modern implementations still add an arbitrary restriction.

[asveikau]

There's a shocking amount of systems that still have 32 bit time_t.

Linux and glibc only started supporting it on 32bit systems in the current decade.

[kelnos]

I mean, we still have 14 years to go. It's not like it's 1999 and everyone is freaking out about y2k. We still have plenty of time.

That doesn't mean it's fine to wait and leave it until the last minute, but we have quite a few last minutes left at this point.

[lloeki]

> we have quite a few last minutes left at this point.

    C’est l’histoire d’un homme qui tombe d’un immeuble de 50 étages.

    Le mec, au fur et à mesure de sa chute, il se répète sans cesse pour se rassurer:
    
    "Jusqu’ici tout va bien."
    "Jusqu’ici tout va bien."
    "Jusqu’ici tout va bien..."

    Mais l’important c’est pas la chute, c’est l’atterrissage.

Tx'd:

    There's this story of a man falling off a 50 floor building. Along his fall the guy repeats to himself in comfort:

    "So far, so good"
    "So far, so good"
    "So far, so good..."

    What matters though is not the fall, but the landing.

- Hubert, in La Haine (1995), Mathieu Kassovitz

https://youtube.com/watch?v=U-v6QVlpReU

[bobmcnamara]

Debian conversion should be done mid2025.

[DvdGiessen]

When implementing a tiny timing library in JS a few years back I found that most engines indeed seem to cast the value to an integer (effectively flooring it), so in order to get consistent behaviour in all environments I resorted to always calling Math.ceil on the timeout value first [1], thus making it so that the callbacks always fire after at least the given timeout has passed (same as with regular setTimeout, which also cannot guarantee that the engine can run the callback at exactly the given timeout due to scheduling). Also used a very similar timeout chaining technique as described here, it works well!

[1]: https://github.com/DvdGiessen/virtual-clock/blob/master/src/...

[blixt]

JS numbers technically have 53 bits for integers (mantissa) but all binary operators turns it into a 32-bit signed integer. Maybe this is related somehow to the setTimeout limitation. JavaScript also has the >>> unsigned bit shift operator so you can squeeze that last bit out of it if you only care about positive values: ((2*32-1)>>>0).toString(2).length === 32

[tubs]

I assume by binary you mean logical? A + b certainly does not treat either side as 32bit.

[blixt]

Sorry, I meant bitwise operators, such as: ~ >> << >>> | &