Having some weird issues with DateTime.now() recently. I have been using this code for several months without any issues. On my system, it is running fine. However, another person’s system has spewed out weird timestamps in the past 24h.
Here is the following sample code:
local Timestamp = DateTime.now().UnixTimestamp
print(Timestamp)
On my system, it will output normal values:
1681218284 -- Relative: 3 minutes ago
but on the other person’s system, it is outputting the following values:
1681129853 -- Join 1, Relative: 1 day ago
1681181211 -- Join 2, Relative: 10 hours ago
These timestamps have been recorded for each place rejoin attempt, within 30 minutes of each other.
Does anyone know why this happens?
I think it works by device time so that user may have manually changed the time on his device to do this, you can try this by changing the time on your device and seeing if it makes a difference.
The system time is not the cause here, the person’s system time is always set to California time, these timestamps relatively range from 10h to 24h which is still a huge gap when compared to UTC time!
Should also note this is the first thing I suspected and I manually changed my system time and could not replicate this issue.
Happens on the client for this specific individual, which is a very strange anomaly and I am trying to figure out what may be causing this issue. And it’s definitely not the user’s system time.
This only started happening in the past 12 to 24 hours. Not sure why
Well I Dont know then, A part from the client changing local time, or you saving the wrong number. This chouldn’t rly be hapening, may be try using the tick() method instead, and se if the same problem is still there?
As stated in the post with the code sample, we are using UnixTimestamp. We need this and only this piece of information. Not sure how you think fromUniversalTime may be useful
Changing system time does affect DateTime and the return values of its functions
What are you using DateTime for? Maybe there’s other alteratives worth exploring
Edit:
I did some testing and apparently DateTime.now().UnixTimestamp returns milliseconds (instead of seconds which the DateTime api suggests) which may explain time discrepancies?
If your systems don’t account for this then it may be the issue?
EDIT: I still don’t understand the cause of the original problem, but GetServerTimeNow() resolved this issue with the specified user experiencing this problem, and appears to be a valid alternative for my particular use case.
My following use case is to create a timestamp 20 minutes ahead of the current UTC time and the client would display the time remaining (a countdown so to speak) by comparing the server’s timestamp and the client using the same DateTime method.
This has never been a problem for many months on various system times. Though as an alternative I think GetServerTimeNow() may be the solution to fix these discrepancies, as long as it remains consistent between different places within the experience
Okay. There’s the issue: DateTime.now() when retrieved from the server will always be different from DateTime.now() called on the client, unless the client and server share the same timezone.
A simple fix would be to have your clients use the server time, instead of using their own local time functions. Personally I have a script that updates a workspace Attribute that has the server’s os.time() as a value
Yeah, it’s pretty weird, I just don’t understand why this was not the case 24 hours ago. People of varying time zones had the correct time on the countdown displayed. Either way, I prefer my edited solution above.
