[yifanl]

If we're pedantic, this doesn't actually do what's advertised, this would be waiting X timeouts worth of event cycles rather than just the one for a true Big timeout, assuming the precision matters when you're stalling a function for 40 days.

[keithwhor]

I haven’t looked at the code but it’s fairly likely the author considered this? eg the new timeout is set based on the delta of Date.now() instead of just subtracting the time from the previous timeout.

[yifanl]

No, it pretty much just does exactly that.

    const subtractNextDelay = () => {
      if (typeof remainingDelay === "number") {
        remainingDelay -= MAX_REAL_DELAY;
      } else {
        remainingDelay -= BigInt(MAX_REAL_DELAY);
      }
    };

[keithwhor]

Oh yikes. Yeah; not ideal.

[Aachen]

To be fair, this is what I expect of any delay function. If it needs to be precise to the millisecond, especially when scheduled hours or days ahead, I'd default to doing a sleep until shortly before (ballpark: 98% of the full time span) and then a smaller sleep for the remaining time, or even a busy wait for the last bit if it needs to be sub-millisecond accurate

I've had too many sleep functions not work as they should to still rely on this, especially on mobile devices and webpages where background power consumption is a concern. It doesn't excuse new bad implementations but it's also not exactly surprising

[keepamovin]

I guess the dream of programming the next heliopause probe in JavaScript is still a ways off hahaha! :)

[sulam]

But it appears that it is consistent with setTimeout’s behavior and therefore likely correct in the context it will be used.

At least if your definition of “correct” is “does the thing most similar to the thing I’m extending/replicating”. In fact you might believe it’s a bug to do otherwise, and JS (I’m no expert) doesn’t give a way to run off the event loop anyway (in all implementations). Although I’d be amused to see someone running even a 90 day timer in the browser. :)

I’ve think a very precise timeout would want a different name, to distinguish it from setTimeout’s behavior.

[gnachman]

That wouldn't very well because Date.now() isn't monotonic.

[_flux]

There is a monotonic time source available in JavaScript, though: https://developer.mozilla.org/en-US/docs/Web/API/Performance...

As I understand it, the precision of such timers has been limited a bit in browsers to mitigate some Spectre attacks (and maybe others), but I imagine it would still be fine for this purpose.

[ericyd]

I don't understand how an implementation detail means it isn't doing what is advertised?

[ballenf]

Each subtracted timeout is a 25 day timer, so any accumulated error would be miniscule. In your example there would a total of 2 setTimeouts called, one 25 day timer and one 15 day. I think the room for error with this approach is smaller and much simpler than calculating the date delta and trying to take into account daylight savings, leap days, etc. (but I don't know what setTimeout does with those either).

Or maybe I'm missing your point.

[zeroonetwothree]

You don’t need to take into account daylight savings or leap days when dealing with unixtime.