Then there are also gotchas like these[0][1]:
> As specified in the HTML standard, browsers will enforce a minimum timeout of 4 milliseconds once a nested call to setTimeout has been scheduled 5 times.
Still, the issue is rather how to measure the elapsed time reliably, for unit-tests among other things.
[0]: https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...
[1]: https://html.spec.whatwg.org/multipage/timers-and-user-promp... (first Note)
See: https://developer.mozilla.org/en-US/docs/Web/API/Window/setT...
Is there even such a thing? You're at the mercy of the platform you're running on. And Windows, Linux, Mac, Android, and iOS are not realtime to begin with.
I guess if you're running on a realtime platform but in a VM like JS does, you can then take that property away, downgrading the "language" from being realtime. I wouldn't call that a language property still though, maybe my VM implementation doesn't make that downgrade after all.
setTimeout() does not actually guarantee to run after the elapsed time. It merely gets queued for the next async execution window after that timer elapsed. Hence it can also be off by infinity and never get called - because JS is single threaded (unless you use a worker - which comes with its own challenges) and async windows only open if the main thread is "idle".
Usually, this is very close to the time you set via setTimeout, but it's very frequently slightly off, too.