As a Roblox developer, it is impossible to get the current UTC Unix timestamp with the same level of precision tick() offers, since os.time is only on second level precision.
Second level precision is not enough for many use cases. Often I want the server to send the client a timestamp in the future with precision without having to consider timezones myself as a developer.
Yes, it’s possible to approximate the timezone difference via calculating from tick(), but this is and imprecise solution because we can only send and receive remote events at a 20-30Hz interval. Therefore, this limits the precision at which travel time can be estimated.
My proposal would be to add a method such as os.precisetime(), a function which will offer the same level of precision as tick(), but be UTC-based. There is plenty of precedent for modifying the standard library, Roblox’s os library and debug are examples of this. Alternatively, precisetime() could be made a built in. os.precisetime() would work both on the client and on the server and be as synchronized as possible.
Having a networked timestamp available in-engine would be a great quality of life update, whether that be a UTC timestamp or some other mechanism allowing for near-synchronization of timed events.