I know we don’t hardcode that value, but that doesn’t matter. If a client sends a “-0800” offset to the server because that client is in California and it’s summer, I think that doesn’t tell the server anything useful at all.
Anyway, using Date().toISOString() does produce the kind of string I think we should send from Client to Server.
Well, actually if we receive a date with -0800 from the client, that is enough information for the server to convert to their own timezone before saving on the DB, and then when the client needs that information again, the server will get the client timezone through their UserProperty(save client TZ) on the DB and will use that UP to convert to the client timezone. So, we only use that “-0800” to convert from “Client → Server” to convert it back we use the UP. So, the bottom line is, if that offset is right, I don’t see any problem using it. Please let me know if I am missing something @bistenes .
@bistenes those offsets are basically transient. Their TTL, in my understanding, just the lifespan of an HTTP request.
Having said that I support the changes you have suggested for the wiki.