Time & You: A Quick Reference for All Things Roblox and Time

Resources Community Tutorials
#1

This tutorial is my attempt to document Roblox’s many time-related features. This is in no way comprehensive or even well-polished, so suggestions and feedback are more than welcome. If you have relevant examples, caveats, notes or really anything: please do reply!

Small disclaimer: This is intended to be a surface-level guide. As always, there are exceptions and details that I simply can’t cover here. Partially because they are not well-documented anywhere, and partially because I am not knowledgeable enough to do so anyway. Things like leap seconds creating UNIX timestamps that point to two points in time, leap smearing affecting microsecond accuracy, monotonicity, etc, are not covered. But if you have information on how Roblox handles these, please do reply :slight_smile:

Accuracy is the documented figure to which you can assume a given timestamp is true relative to what it attempts to measure. E.g., if a function is documented as measuring the number of seconds since the UNIX epoch, you can assume it is accurate to 1 second.

Precision is the given number of digits. This can be inconsistent. Decimals past something’s given accuracy should be assumed to be inaccurate/a floating-point error.

Constant is whether this figure is updated in a frame. If a function is constant, then calling it in the same frame will return the same result. This was tested by calling the same function at RunService.PreRender and then again at RunService.PostSimulation, which should be at two ends of the Task Scheduler frame pipeline.

Universal is whether this figure should be universal across clients or the server. This does not necessarily mean they are synced. E.g., os.time() should return the number of seconds since the UNIX epoch. This should be a universal value, but since it relies on each client’s own set time, it can be desynced from other clients and the server.

Getting time

os.time()

  • Returns the number of seconds since the UNIX epoch.
  • Accuracy: 1 second
  • Precision: 0 digits; 1 second
  • Constant: No
  • Universal: Yes

os.clock()

  • Returns the number of seconds of CPU time used by a program.
  • Accuracy: <1 microsecond
  • Precision: 7 digits; 1/10th of a microsecond
  • Constant: No
  • Universal: No

tick() - Deprecated

  • Returns the number of seconds since the UNIX epoch, on the computer the code was ran on
  • Accuracy: ~1 microsecond
  • Precision: 7 digits; 1/10th of a microsecond
  • Constant: No
  • Universal: No
  • See this post for deprecation info, tick() has large discrepancies and an alternative should almost always be used

time()

  • Returns the time since the game began on the computer the code was ran on.
  • Accuracy: 1/240th of a second
  • Precision: 17 digits; 1/100th of a femtosecond
  • Constant: Yes
  • Universal: No

elapsedTime() - Deprecated

  • Returns the time since Roblox started running.
  • Accuracy: 1 second
  • Precision: 13 digits; 1/10th of a picosecond
  • Constant: No
  • Universal: No
  • Inconsistent behavior across OSes, can be extremely outdated on mobile

workspace:GetServerTimeNow()

  • Returns the number of seconds since the server began.
  • Accuracy: 1 microsecond
  • Precision: 6 digits; 1 microsecond
  • Constant: No
  • Universal: Yes

workspace.DistributedGameTime

  • Returns the time since the game has been running on the computer the code was ran on.
  • Accuracy: 1/60th of a second
  • Precision: 16 digits; 1/10th of a femtosecond
  • Constant: Yes
  • Universal: No

DateTime.now().UnixTimestamp

  • Returns the number of seconds since the UNIX epoch. Identical to os.time()?
  • Accuracy: 1 second
  • Precision: 0 digits; 1 second
  • Constant: No
  • Universal: Yes

DateTime.now().UnixTimestampMillis

  • Returns the number of milliseconds since the UNIX epoch
  • Accuracy: 1 millisecond
  • Precision: equivalent to 3 digits; 1 millisecond
  • Constant: No
  • Universal: Yes

RunService time and deltaTime event parameters

  • RunService has multiple events tied to various stages in the Task Scheduler pipeline. Each one has time and/or deltaTime parameters that measure the time since the last event in the previous frame, and/or the time to the event in the next frame. See Quenty’s reply in this thread for more details.
  • Accuracy: Variable, from 1/60th to 1/241th of a second.
  • Precision: 17 digits; 1/100th of a femtosecond

Using time

os.difftime(t2, t1)

  • Returns the difference between two times, t2 and t1 must be integers representing seconds since the UNIX epoch
  • Accuracy: 1 second
  • Precision: 0 digits; 1 second
  • Constant: Yes
  • Universal: Yes

DateTime

DateTime is as a useful data type that allows you to store timestamps, accurate and precise to the millisecond, in DateTime objects. From these, you can convert them to local (timezone-specific) times and dates, convert them back, and even get human-readable strings from an otherwise arbitrary timestamp.

Examples

Benchmarking: Store the initial time of os.clock() in a variable, run a loop, then print the difference between the current os.clock() and the stored os.clock() to get a high-accuracy benchmark of the time it takes for your loop to finish.

Getting server uptime: Call workspace:GetServerTimeNow() and truncate its decimals to get the number of seconds the server has been running, on either the client or server.

Measuring frame rate: Divide 1 by the RunService.PostSimulation() parameter, deltaTimeSim to get how often the client or server updates its physics simulation. I.e., its frame rate. Note that the physics simulation may pause under heavy load, or if explicitly paused. Use RunService.PreRender()'s deltaTimeRender if you would like to account for this, however running code in the render step may negatively affect your players performance.

Converting a date and time for each player’s timezone: Convert your date to a DateTime object through one of its various constructors. Pass this object to the client, and have the client use DateTime:FormatLocalTime() to get a string you can use to display a given date and time in a player’s local timezone.

Thanks

19 Likes
#2

This returns tick() for a specific consistent timezone. That means, it will be the same on the client and the server no matter where in the world they both are.

tick() is more accurate than a second. It goes 4-8 decimals deep from what I remember.

4 Likes
#3

Updated the post, thanks!

The documentation for tick() only mentions it returns the number of seconds, without mentioning precision. Since I can’t find an authoritative source for how precise tick() is, I can’t really say how accurate any of the decimals are.

It’d be great if Roblox made a documentation page like this for us, as it stands the documentation is too vague for me to give any answers without playing it safe.

I’ve edited it to say “precision is ?” but if anyone has a better idea on how to express this uncertainty, that’d be great too.

1 Like
#4

Here’s a tip: you can test how much precision tick has, by simply writing print(tick()) into Roblox Studio’s command bar (Don’t remember if you need to be in playmode or not.)

2 Likes
#5

Forgot to reply to this, sorry!

The problem is there’s no documentation to confirm the accuracy of those returned decimals.

For example, os.clock() returns many decimals, at times well past the millionths place the documentation guarantees accuracy to. These decimals, although given, can’t really be trusted for anything.

I doubt there’s a use-case for beyond microsecond precision in Roblox, but the point stands with other, less accurate methods for getting time like tick().

1 Like
#6

Seems pretty precise to me:

image

print(tick()) --> .020084
print(tick()) --> .020172

print(tick() == tick()) --> true
#7

Thanks for compiling this all here, great to see it all condensed into one place.

2 Likes
#8

Avoid using tick():

1 Like
#9

Thanks! I’ve never really used tick(), so I had no idea. I’ve edited my post.

1 Like
#10

This post has more details on tick().

  • 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.

Emphasis mine. I was unaware of this info on tick(), I’ve always used an alternative. Regardless, even more so now, there’s no guarantee for the precision of tick(). I’ve edited my post to reflect these details.

1 Like
#11

Bumping this because I’ve re-written this entire post to make it easier to read by including relevant definitions and adding specific details to each description. I’ve also updated some definitions, added a quick overview of the DateTime object, compressed the various RunService event parameters into one section, and added some hopefully useful examples.

1 Like
#12

More accurately, time() is physics time step. Listening to Stepped gives you both the time, and the NEXT dt for the physics frame!

If you’re seeing jittering on your camera springs attached to physics objects or stuff? Connecting to time, including the forward prediction can fix a lot of stuff.

1 Like