question

(edit)

Good news! As of our latest update, we've managed to get the clock drift down considerably. In fact, we're down to max of 1 second of drift between servers, so depending on your scenario, you should be able to tighten up the times you use in your logic checks. I'll also promote this to be the top answer, so that folks finding this thread for the first time have the latest info.

(end of edit)

That's correct - a standard issue with massively scalable online systems is that there will be clock drift between servers. That's why, with backends like PSN and XBL, they only re-sync the client to the server's clock if they're more than a couple of minutes off. We've taken steps to minimize this drift, but a small amount is unavoidable in the individual server times - currently, it should be less than 30 seconds.

It isn't really possible for us to "lock" a players calls to one server, as we use a variable number of backend servers depending on the total load we're experiencing, and those calls have to be distributed across all of them. A dedicated time-of-day service would be one way to approach this, but you would still need to account for the latency in querying for the time. A simpler approach would be to log the start time in the player profile, and let the client be semi-authoritative about the time. That is, allow the client to track the time, so that it has a high level of consistency, but when the upgrade time expires, that causes the client to call a Cloud Script which checks the timestamp, time required, and current time, to validate that the client isn't trying to cheat (giving the client a small amount of leniency to account for the clock drift).