os.time() returns whole seconds of current time.
time() is more usable for current time running in-game.
tick() is getting deprecated and could be replaced.
os.clock() has one of the highest resolution of time. I think there was a reply mapping out the differences
But for very precise measures, what should I use?
Found the reply!
os.time() would be the best.
for an example,
local foo = tick() -- 100.00147 tick is more advanced local bar = os.time() -- 100 -- os.time is like a math.floor of tick
From what I know os.time() does not use the local player clock if it is on the server, I think it was an error:
I would use os.time() with the datastore, when the reward is taken, it will save the number that os.time() gives and the next time I need to take the reward and if I really spend that time I could get the money, so the player does not lose the reward if you disconnect.
Or you could also save the 3 hours in seconds and when it reaches 0, it will be charged and restarted.
Never reward things to the player on the client, if os.time() is local to the machine (idk if it is) it’d be local to the server.
os.time isn’t relative to the client’s pc time, it wouldn’t be exploitable, and another reason for that is that you’re probably handling this on the server.
And I also have an alien ray gun, that depends on using tick() too see if the player doesn’t shoot without a debounce. What would be best using for that? time or tick or os.time()?
tick will soon be deprecated, better alternative is to use
os.clock. You may be thinking why not use
time instead? Here are the reasons below:
It has less precision than
It will lag and return no so accurate results if physics simulation lags.
On the other hand,
os.clock is far more accurate and isn’t affected my physics simulation.
Returns the amount of CPU time used by Lua in seconds. This value has high precision, about 1 microsecond, and is intended for use in benchmarking.
int os.time ( table time = UTC time )
Returns how many seconds have passed since the Unix epoch (1 January 1970, 00:00:00), under current UTC time. If provided a table formatted similarly to that returned by
os.date , it will return the number of seconds since that time instead.
Returns how much time has elapsed since the current instance of Roblox was started.
In Roblox Studio, this begins counting up from the moment Roblox Studio starts running, not just when opening a place.
Returns how much time has elapsed, in seconds, since the UNIX epoch, on the current local session’s computer.
The UNIX epoch is represented by the date January 1st, 1970 .
Returns the amount of time, in seconds, that has elapsed since the current game instance started running.
If the current game instance is not running, this will be 0.
Seems like there might be a bit of confusion here. Here’s a rundown of what you really need to know:
time() to measure time within a game in the same environment (e.g. don’t use it to calculate time between server and client). It will return a high-precision time since the game started. Useful for finding delta times for all sorts of things. You will probably end up using
time() more than anything else. Edit 2023:
time() gets updated every
RunService.Stepped event, so it’s not really “high-accuracy” but great for most game-dev related stuff.
os.clock() is high-precision and good for benchmarks. Also useful for the same thing
time() does but in non-runtime environments (e.g. plugins). If you’re writing modules that you might distribute to others, it might be best to use
os.clock() instead of
time() for the sake of being compatible with plugins.
tick() may be deprecated, so don’t use it.
os.time() returns a second-precision unix time. It should be used server-side and is useful for saving timestamps for player/game data. It is supposed to be consistent across all Roblox servers.
Maybe you can request a timestamp from the client to the server. Then you can measure the time on the server and send it back.
Using tick() should be okay I think.
What do you need the ‘precise measures’ for if you are trying to measure hours?
So this is for weapon debounces and simillar.
This is for measuring time when it is not VERY important that the time is on the micro second.?
time is for weapon debounces. It has high precision and is reliable at runtime.
I’m not sure why you shouldn’t use os.clock at runtime, but you definitely don’t need to. It goes into exactness that you will never need in a game.
I would use
time() for those debounces.
os.clock() could be used to do benchmarking to figure out how fast an algorithm is. It’s not really necessary for things like weapon debounce.
I only use
os.clock() if I need a
time()-like interface outside of runtime, such as plugins.
So time() substitues tick() in most cases? Thanks for your answers!
tick won’t be affected by physics simulation while
time would be.
So you’re saying if the game has lots of lag; time() might not work as intended?
That is correct, it would throttle and give not so correct results.
Damn, so what should I use then? Like, what substitutes tick()? And is it even worth switching from tick() for things like local debounces @sleitnick and @SilentsReplacement ?
os.clock as a replacement for
Correct. I do agree with you, It might be helpful in terms of development.