Os.time() is not synced across Roblox servers

[mygame43]

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

[berezaa (Bereza)]

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)

[zlib]

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

[Polymorphic]

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.

[kratos3089]

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

[Xan_TheDragon (Xan)]

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

[wravager]

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

Are os.time() and tick() guaranteed to be synchronized on the server?

No. os.time() is based on UTC, tick() is based on the timezone the server is in. “This differs from tick(), because tick uses the current system time rather than UTC time.”-Roblox Wiki

[nin900500 (nin)]

Any word on the status of this issue?

[dillanrules]

I made a quick synchronization script so that you’d be unaffected by this issue.

--this module will sync the time() function with google's time. will block on first load so it can sync the time

local module = {}
local httpServ = game:GetService("HttpService")
local reqAsync = httpServ.RequestAsync
local months = {Jan=1,Feb=2,Mar=3,Apr=4,May=5,Jun=6,Jul=7,Aug=8,Sep=9,Oct=10,Nov=11,Dec=12}
local offset = 0

module.time = function()
	return os.time() + offset
end

function updateTime()
	local succ, resp = pcall(reqAsync, httpServ, {Url="https://google.com"})
	if succ and resp.Success and resp.Headers.date then
		local day,month,year,hour,min,sec,tz = resp.Headers.date:match("%a+, (%d+) (%a+) (%d+) (%d+):(%d+):(%d+) (%a+)")
		if day and month and hour and min and sec and tz then
			succ, resp = pcall(os.time, {day=day,month=months[month],year=year,hour=hour,min=min,sec=sec,tz=tz})
			if succ then
				offset = resp-os.time()
			else
				--this should never happen unless google goes away
				if module.onError then 
					spawn(module.onError)
				end
			end		
		else
			--this should never happen unless google goes away
			if module.onError then 
				spawn(module.onError)
			end
		end
	else
		--google is down or we're blocked or something
		if module.onError then 
			spawn(module.onError)
		end
	end
end

updateTime()
delay(30, updateTime)

return module

[Dyljuann]

Do you know if google’s response date/time will change depending on the timezone the server computer is in?

[XAXA]

The date header is in UTC, so it is unaffected by timezones.

[Dyljuann]

Oops, I didn’t know about that. Perfect thanks!

[XAXA]

Actually, I’m completely wrong. The timezone could be anything, but converting that to unix standard time would result in the same time regardless of the timezone.

[EncodedLua (Juniper)]

I get that Roblox usually has a lot of issues the engineers are working on at any given time, but personally I think this issue should be shot directly to emergency status and fixed as soon as possible. This has been an issue for at the very least a year and a half at this point and would be a critical issue to any network of servers as large as Roblox.

System clocks being out of sync creates a variety of issues - a prominent one being it’s now very difficult or practically impossible to create any sort of robust player save-locking mechanism, meaning data store failures are near impossible (if not completely) to mitigate by us developers. For the sake of this bug report I’m going to omit the frustrations with the data store API as we’ve all heard them 10000 times. Me and @IntegerUnderflow (sysadmin for Team Adopt Me) have experienced Roblox servers with unix timestamps COMMONLY UP TO AN HOUR OUT OF SYNC.

I don’t usually get very frustrated with engine bugs, but whenever players lose data, the developers of the games they play are the first ones that are understandably blamed. Issues like this make working with data stores on Roblox one of the most headache-inducing, sleep-depriving tasks on the platform. I really hope that this is addressed at the very latest by the time query transactions are rolled out for data stores because this is a system flaw that probably has more repercussions internally than we can see at a high level.

TL;DR: We should not have to resort to this in order to get an accurate UTC timestamp:

@dillanrules

I made a quick synchronization script so that you’d be unaffected by this issue.

[kratos3089]

Hello, we used to have problems around time syncs on game servers last year that were fixed in early Q2.

If you can still reproduce this problem, if you could send us the jobIds for the servers you see a time drift between, that would help us track this down much more quickly.
You can obtain this using

game.JobId

Thanks!

[LucasMZ_RBX (lucasmz)]

Sorry for the bump, but I can’t find any official statements that this has been fixed. Has this been resolved? It’s crucial for session locking and it could cause problems with data.