Os.time() is not synced across Roblox servers


#1
  • Describe the bug. Describe what is happening when the bug occurs. Describe what you would normally expect to occur.
    os.time is not synced across all Roblox servers. This makes using the API useless because it is unreliable.

  • How often does the bug happen (Everytime/sometimes/rarely)? What are the steps that reproduce the bug? Please list them in very high detail. Provide simple example places that exhibit the bug and provide description of what you believe should be the behavior.
    This bug is happening every time.

  • When did the bug start happening? If we can tie it to a specific release that helps us figure out what we broke.
    Our earliest report of this was February 5th.

  • Would a screenshot or video help describe it to someone? If so, post one.


    I tried to run both print statements at the same time on different servers but I’m typically 1-2 seconds slow. Regardless, these are the results from my test. I would estimate each server to be within 1-100 seconds out of sync with the correct time. This has lead to us removing daily rewards system from our games because players are able to infinitely collect them if they rejoin quick enough after claiming the reward.


#2

Can confirm. We’ve seen servers as much as 3-5 minutes out of sync. It caused serious issues in Vesteria when we were trying to store player data across teleports. Players would find a server that’s behind once in a blue moon and then drop items there and teleport back to a newer server, and the game wouldn’t recognize that save as their newest one because the server’s clock was off. They were able to duplicate super rare items because of this.

We ended up switching to incremental version numbers for player data and it fixed the problem, but yeah it’s pretty messed up that server time can vary so wildly.

(@Kampfkarren might want to look into switching DataStore2 over to an incremental version number (just add 1 to every save instead of using os.time()) to avoid issues with this timestamp inconsistency)


#3

This has been happening since late december-early january, every server i join is usually minutes apart from the last, and at worst they’re hours apart. They’ve also been drifting further since then, as the problem has only gotten worse


#4

If it isn’t possible to have accurate os.time synced across servers, then this must be documented on the wiki. This undocumented issue (or bug, if it is one) caused @berezaa and me weeks of headache.


#5

Thanks for the report. We’re actively working towards a fix for this.


#6

I assume this also affects tick()? I don’t know how tick works compared to os.time() aside from that it includes a decimal value.

I’ve also noticed desyncs between tick() and os.time(). I have a daylight script that uses formatting in os.time() to get UTC Epoch and tick() to get a decimal value for the time, adding these two together for an epoch relative to UTC + milliseconds. This suffers issues where tick() will move to the next second before os.time() resulting in the sun jutting backwards while os.time() is still one second behind, and the decimal value for tick() is near zero due to being on the next second.

If it helps to visualize this problem, here’s the output of time from the script:

1550289678.9726 --Counting...
1550289678.9886 --Counting...
1550289678.0063 --tick() rolled over, os.time is behind by one second
1550289678.0225 --os.time still catching up
1550289679.0394 --os.time finally moved over to the next second

#7

I don’t think they are supposed to be synced. os.time() is unix time while tick() is based off of system time.

os.time() Returns how many seconds have elapsed since the UNIX epoch (1 January 1970, 00:00:00), under UTC time.

tick() Returns the amount of time in seconds since the UNIX epoch (January 1st, 1970) on the current local session’s computer. It is precise to the nearest millisecond (0.001s).