Repository navigation
os.uptime returns float instead of integer #41636
Description
Activity
Some history #12291.
Yes I've noticed this too. There was a change in libuv (libuv/libuv@77a2394) which now reads
/proc/uptimeinstead of usingclock_gettime(CLOCK_MONOTONICand/proc/uptimecontains a fractional output. So either this behavior should be changed or the docs should be adjusted to say that it is a fractional number on some systems. I would prefer fractional seconds, since a math.floor is easily doable and a higher precision might be useful sometimes.I created an additional issue for this in libuv libuv/libuv#3447
It depends a bit on how you define a breaking change, there is no datatype change so nothing what totally breaks. But yeah it can lead to strange behavior if someone relies on an integer. I found this issue since some number formatting code of ours relied on integers.
However for quite a while windows has returned fractionals in this API, which also was changed.
libuv already returned fractional uptime for some architecture, just did a PR there to return fractions on win. So changing this to round down would be a "breaking" change too, especially since some versions are already released with this behavior. I really think updating the docs accordingly is best.
I can do a PR if wished for.
This should be fixed as #42340 has landed
Version
v14.18.3
Platform
Linux 5.4.0 #1 SMP Thu Apr 22 16:18:59 MSK 2021 x86_64 x86_64 x86_64 GNU/LinuxSubsystem
os
What steps will reproduce the bug?
I just upgraded from Node.js 12 to 14 (on Ubuntu via nodesource repository) and found that
require("os").uptime()now returns a float and no longer an integer as the documentation states. Tested on Ubuntu 18.04 on VirtualBox and Ubuntu 20.04 on a Virtuozzo container. So this is either a bug or the documentation needs an update.How often does it reproduce? Is there a required condition?
No response
What is the expected behavior?
os.uptimeshould return an integer.What do you see instead?
os.uptimereturns a number that is not an integer.Additional information
No response