OS.date is inconsistent in studio vs in game

When using os.date in game vs in studio, it prints conflicting information.

For this bug, we’ll be using the code print(os.date("*t").hour)

We expect this, will print the hour of the UTC time standard/GMT; across all platforms. Studio does not do this, it uses the local timezone not UTC.

We expect as the os.date API says that if a time is not given, it will use os.time which uses UTC while (as an example) tick() uses the local timezone of the client.

Bug repo in multiple environments

In game via dev console
Local time: 19:37 | UTC: 18:37 | This is correct behavior

In game via script
Local time: 19:39 | UTC: 18:39 | This is correct behavior

In studio, not playing the game (eg not pressing play)

Local time: 19:40 | UTC: 18:40 | This is incorrect behavior

In studio, pressing play

Local time: 20:01 | UTC: 19:01 (Tested twice) | This is incorrect behavior

In studio, local server as the server
Local time: 20:03 | UTC: 19:03 | This is incorrect behavior

print(os.date("!*t").hour) prints the correct results, regardless of studio/player


Local time: 20:22 | UTC: 19:22 | This is correct behavior

Testing print(os.date("*t", os.time()).hour) also shows incorrect information.

os.date("*t", os.time())

In game.
Local time: 11:11 | UTC: 10:11 | This is correct behavior

In studio
Local time: 11:13 | UTC: 10:13 | This is incorrect behavior

Test results from the US

As I’m in the UK, which is one hour from UTC while in summer, let’s verify that against the US. For this, we’ll re-test studio vs in game.

In this case, we are using IP:, or server NordVPN US#3457. This server is located in New Jersey and we expect this to our local time to be in EDT (UTC-0400).


In game:
EDT: 6:26 | UTC: 10:26 | This shows correct behavior

In game:
EDT: 6:32 | UTC: 10:32 | BST: 11:32
This is my local time even if studio shows otherwise. To validate this, I asked @jody7777 who’s timezone is PT to complete the same results and it printed 3.
This is still incorrect behavior.

As these tests created such abnormal results, this shall not continue.

At this moment we looked into this further from the eyes of vanilla Lua. We found that adding “!” uses UTC while using just “*t” uses local time. We can suggest that server clocks are set to UTC.

Based on all of the above, while this bug still occurs, it should be better certificated on the DeveloperHub. See that post here:


I think this issue is related to Os.time() is not synced across Roblox servers.

Across Servers, but this was studio and on Server.
Maybe I’m wrong.

1 Like

While both is about os.time() [in some way] being incorrect, that bug is specifically that across servers time is not in sync and based on reports this is approx 3-5 minutes; while this bug is about os.date("*t") being incorrect across studio and in game. Within studio, it uses the local timezone, as per my notes on each test entry; while in game it uses the correct UTC timezone.

Although I did test if it os.time() being inaccurate in the same sense as my bug.

os.time test

Here in studio

And in game

These are all accurate and use the correct timezone

1 Like

Is there any updates from Roblox about this?

I just double checked this. This is intended behavior, and perhaps a matter of our docs not being descriptive enough.

I tested this with both client/server side calls in both studio and online. Left screenshot is studio, right is online. Grey is os.date("*t") and blue is os.date("!*t"). Online test came a few minutes after the studio test. My clock was saying about 2:45 PM, which is reflected in the bottom left square in each screenshots.

I believe the page has been updated since this was posted; give it another check. Generally speaking, if your gameplay is at all time-based, you should be using os.date("!*t") (UTC) on both the client and server because you need to guarantee the value is close to consistent across all correctly-configured devices.


Seems all fine. Thanks for the confirmation, I can confirm the docs are correct and live.

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