What is os.clock?

What is os.clock, and what even is os?

image

local Time = os.clock()
task.wait(1)
print(os.clock()-Time)

image

2 Likes

What does this even means? And how do you use os.clock?

(os | Documentation - Roblox Creator Hub)

os.clock() would probably be best used when benchmarking code and seeing how fast/slow something is executed.

tick() is good for things like input/ability/interaction cooldowns and things like ingame timers. (more relative to ingame stuff)

os.time() is great for saving/comparing timestamps, especially if you use os.date("!*t", os.time()) to convert it to UTC, and then you dont have to worry about servers timezones. (NOTE: os.time() doesn’t have millisecond precision)

there is many ways to compare time.

local cooldown = 0

function handleAction()
    if tick() >= cooldown then
        cooldown = tick() + 0.5 --reset the cooldown to half a second.
        --handle action
    end
end

or

local cooldown = 0.5 --set the cooldown to half a second
local last = 0

function handleAction()
    local current = tick()
    if current - last >= cooldown then
        --handle action
        last = current
    end
end

I usually prefer the first approach, although the second seems to be used more conventionally and all functions (tick(), os.clock() and os.time()) can be compared this way, with a minor exception to what os.date(“!*t”,os.time()) returns.

2 Likes

Not really, Its recommend that you dont use tick(), and instead use os.time() for the same purpose as its faster and more precise, tick() may also get Deprecated in the future, and os.time() is also based off of UTC time, while tick() is based off of Device Time.

2 Likes

os.time() cant be used for fractions of a second though (which is quite useful for some input cooldowns/timers), and i usually used tick() or os.clock() because they had more precise timing on such things.

i didn’t know about the possible deprecation of tick() though

1 Like

tick() sounds perfect - it has a high resolution (usually around 1 microsecond), and a well-defined baseline - it counts since UNIX epoch! Or, well, it actually doesn’t. On Windows, it returns you a variant of the UNIX timestamp in local time zone. In addition, it can be off by 1 second from the actual, real UNIX timestamp, and might have other idiosyncrasies on non-Windows platforms. We’re going to deprecate this in the future.

Source

2 Likes

thank you for the information.

DateTime.now() exists for that

1 Like

No. Terrible advice. Tick() is ok for cooldowns but if you validate against a server it is terrible. While tick() does have millisecond accuracy it is local epoch time relative to your timezone. For example if you do a tick() on client then tick() on server and then compare the timestamp cooldowns youll quickly find out they differ due to timezone difference.

Someone mentiond DateTime.now() but thats DateTime object. You really want to use DateTime.now().UnixTimestampMillis.

when would you be comparing a cooldown?

for my systems i have cooldowns on the client and cooldowns on the server. instead of comparing a cooldown to see if its valid, i check if the cooldown is done on the client → fire a remote → see if cooldown is done on the server.

no need for comparing cooldowns here. also prevents clients from sending spoofed data to confuse your systems.

also os.clock > tick

1 Like