Lastuser currently offers an account timezone that is propagated to client apps. Client apps will use the user account timezone if known, defaulting to app timezone, typically Asia/Kolkata.
This archaic approach has no place in a mobile first world where users expect the timezone on their device to be the only one that matters.
Baseframe should adopt Lastuser's timezone detecting library and use it all the time. The client-set cookie can have a one hour timeout so that it's periodically refreshed in case the user is travelling.
Lastuser should lose the account timezone column. There is no current use case for it and the potential for confusion exceeds currently known benefits.
Pending problem: what timezone is used for the first render without a user timezone cookie? Options:
- Auto-detect from the user's IP address. This is not reliable.
- Render dates in UTC but annotate them using
<time> tags for the client to correct in JS.
Lastuser currently offers an account timezone that is propagated to client apps. Client apps will use the user account timezone if known, defaulting to app timezone, typically
Asia/Kolkata.This archaic approach has no place in a mobile first world where users expect the timezone on their device to be the only one that matters.
Baseframe should adopt Lastuser's timezone detecting library and use it all the time. The client-set cookie can have a one hour timeout so that it's periodically refreshed in case the user is travelling.
Lastuser should lose the account timezone column. There is no current use case for it and the potential for confusion exceeds currently known benefits.
Pending problem: what timezone is used for the first render without a user timezone cookie? Options:
<time>tags for the client to correct in JS.