Tick() returns incorrect number after latest Roblox update

Since the last Roblox update, calling tick() seems to return an incorrect number on some windows computers.

Instead of returning the number of seconds since UNIX epoch, it returns a significantly smaller number (see console screenshot). This seems to happen both in studio and on the client.

image

Expected behavior:

26 Likes

https://developer.roblox.com/en-us/api-reference/lua-docs/Roblox-Globals
The returned value is based on the client/machine it’s called on.

There are discrepancies based on machine clocks and timezones. You may use a system to sync this precise mechanism with os.time() for reasonable live countdowns.

2 Likes

While that might be correct, it’s not related to this bug. tick() has been working normally up until the latest Roblox update.

7 Likes

Oh! I misunderstood. The value is actually very wrong in your screenshot.

2 Likes


Can repro. Tick is reporting it is 01/01/1970 @ 1:49am (UTC)

@Coeptus, I’d suggest using os.time() as it will always be as-accurate as possible and in UTC.

3 Likes

To add on to what @ElliottLMz said, if you wait until os.time() increments (use RunService.Heartbeat), you can synchronize it to be as precise as tick(). It definitely wont be accurate UTC though.

3 Likes

Thanks for letting us know. Our latest update introduced this bug on Windows and we’re working on a fix for it.

11 Likes

@coefficients, This is still an issue!

Are you sure you’re running the latest version of Roblox?

Roblox Studio Automatically Updates upon starting up the program, how could I possibly be using an Out dated versions of Studio without being entirely aware of it?

Usually they Update every Thursday, but even if they made a recent update I am certain that I am running the latest version of Studio.

This happened in an Empty Baseplate.


Some information that might be useful, I’m using Windows 10, did a recent version update yesterday but the OS was installed and been use for almost a year.

2 Likes

Also can still repro but DevRel didn’t say that there was a fix that was published yet so I’m assuming that they’re still finding a fix for it. :eyes:

I’ve had a couple of the users on my game experience this with a daily streak system returning an unrealistic number of hours on the client until it rewards something new, and after reproing this on the server (ingame, not in studio) and client (on studio), it does seem to be client affiliated. Hope this gets fixed soon as my players are slightly confused! :stuck_out_tongue:

EDIT:
@ElliottLMz I would’ve thought that using either method would be totally fine on the server. As I’ve gathered from other posts however, os.time is excessively similar to tick(). The only difference is os.time takes the raw system time, and actually rounds it to the nearest second. There is a nice thread on that here:

The cons with using os.time over tick on the client, however, is that it can be manipulated easily because it is gathered directly from the device you are using, and depending on its use case, it can be altered for malicious intent. tick() doesn’t have this issue (tested by changing my date and time on both, tick continued going up on its value while os.time went down an hour or so), and is definitely the more accurate of the two.

Also the incorrect number always seems to return 3600 plus the amount of time elapsed from when the client is opened (you can test this in studio by counting the number of seconds passed directly after you start up studio) but it’s fairly inconsistent in-game. os.time() on the client seems to be the same as the server and doesn’t take the client’s time unlike tick().

1 Like

Please read a little closer and be patient.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.