On all clients the GetServerTime API, which we have lovingly documented and relied upon for years to give us some semblance of a stable Unix timestamp in this generally unstable and tumultuous world, appears to in fact be but yet another deceiver that would sit upon a throne of lies and cast down upon us return values that are - to great dismay - completely insane in some circumstances.
The expectation is that GetServerTime returns the Unix timestamp of the server that is not impacted at all by the user's local clock. The reality is that if the user's local clock travels backwards - and only backwards - while the client is open, the return value of this API appears to travel backwards with it. The net effect is this API can't be trusted cross-client to return an approximately-synchronized timestamp.
Test case
Log into the client and run /dump GetServerTime()
Adjust your local system clock backwards by two hours. Note that this change needs to affect the clock, not the timezone.
Re-run /dump GetServerTime(). The output will be offset backwards by two hours.
If you exit and restart the client the issue will correct itself.
Example
As a more illustrative example with real timestamps collected by a real human, refer to the following:
I set my system time to be about 20 minutes ahead of the real time - Tue Feb 27 2024 21:01:00 GMT (1709067660) - and started the client.
Upon logging in /dump GetServerTime() reported an approximate timestamp of 1709066518 (Tue Feb 27 2024 20:41:58 GMT), which is within my expectations.
With the client still open, I changed my system time to be about two hours earlier the starting time (from 9pm to 7pm).
Re-running /dump GetServerTime() now reports a timestamp adjusted back by two hours - 1709059338 (Tue Feb 27 2024 18:42:18 GMT). This is not within expectations - the server shouldn't time travel back two hours with me.
With the client still open, I changed my system time to be about two hours ahead of the starting time (from 7pm to 11pm).
Re-running /dump GetServerTime() reported the current timestamp again 1709066573 (Tue Feb 27 2024 20:42:53 GMT) - which is within expectations.
On all clients the GetServerTime API, which we have lovingly documented and relied upon for years to give us some semblance of a stable Unix timestamp in this generally unstable and tumultuous world, appears to in fact be but yet another deceiver that would sit upon a throne of lies and cast down upon us return values that are - to great dismay - completely insane in some circumstances.
The expectation is that GetServerTime returns the Unix timestamp of the server that is not impacted at all by the user's local clock. The reality is that if the user's local clock travels backwards - and only backwards - while the client is open, the return value of this API appears to travel backwards with it. The net effect is this API can't be trusted cross-client to return an approximately-synchronized timestamp.
Test case
/dump GetServerTime()/dump GetServerTime(). The output will be offset backwards by two hours.If you exit and restart the client the issue will correct itself.
Example
As a more illustrative example with real timestamps collected by a real human, refer to the following:
/dump GetServerTime()reported an approximate timestamp of 1709066518 (Tue Feb 27 2024 20:41:58 GMT), which is within my expectations./dump GetServerTime()now reports a timestamp adjusted back by two hours - 1709059338 (Tue Feb 27 2024 18:42:18 GMT). This is not within expectations - the server shouldn't time travel back two hours with me./dump GetServerTime()reported the current timestamp again 1709066573 (Tue Feb 27 2024 20:42:53 GMT) - which is within expectations.