I have run into an issue with a script I am using when it comes to time between the client and the server. Digging into this, it looks like tick() is calculated off the local timezone from a date as opposed to the real unix epoch like the documentation claims it is. The documentation should be adjusted to exclude the terminology, better explain that it is not the real epoch, or tick() should be adjusted to match the actual epoch.
I don’t believe this is a bug.
tick() returns the Unix Epoch, yes, but it can return a variant of the Unix Epoch (this does not happen with os.time())
In a play-testing session, the server is being hosted locally on your computer, so it would make sense that tick() would return the same timestamp for both the client & server.
However, in a real session, who knows where in the world the server is being hosted! So you’ll end up with discrepancies in the timestamp between tick() on the client vs. the server.
tick() is planned to be deprecated, but that announcement was 4 years ago, and who knows what’s going on with that plan now.
At the very least this is probably something that needs to be clarified in the docs.
They aren’t meant to be the same, between clock and tick, client and server.
The documentation should probably be refined for tick(). I would use os.time() but that doesn’t carry milliseconds.
It is true that the documentation does mention local time, but unix timestamps are universally calculated from UTC, not local timezone. I may move this to a documentation issue if the intention is to be calculated from the date on local timezone as opposed to the actual unix epoch.
You’ll probably want to use something like DateTime?