OS.date is inconsistent in studio vs in game

[railworks2]

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

os.date("!*t").hour

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: 23.226.133.174, 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).

os.date("*t").hour

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:

OS.date requires more information

As a result of finding this bug We found that the OS API page, at least in context of os.date() needs some extra information to explain the difference os.date("!*t") and os.date("*t") This information is that the use of the “!*t” caused it to be UTC while just “*t” used local time. This should be clearly noted there on the page.

[LouieK22]

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

[sebi210]

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

[railworks2]

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

[railworks2]

Is there any updates from Roblox about this?

[Ozzypig]

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.

[railworks2]

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