When you first log in to a new Phabricator instance on Phacility, time is set to UTC, which most users likely aren't in. This prompts them immediately to set their timezone and we lose them when they click save, which sends them to settings. Probably a good idea to delay or find another means to not need to distract first time admins.
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T11132 New Phabricator NUX | ||
| Open | None | T11456 Don't lose user in NUX flow because of Timezone issues |
Event Timeline
Comment Actions
In the general (Phabricator, rather than Phacility) case we could also suppress that warning while "NUX Mode" is active, for whatever "NUX Mode" means. Presumably, it's not important to fix until you get through whatever NUX flow we end up with. This would indirectly reduce the annoyance for Phacility instances, although sync is still better.
Comment Actions
I was thinking that the first time they log in, we just take the browser timezone and set the user config to that.
Comment Actions
Most browsers can only give us a timezone offset, like "UTC-7", not a locale name like "America/Los_Angeles". We already attempt to read this value (D15962, T3025#176547) but when I wrote that stuff it was only available in Chrome and not necessarily reliable. We do try to guess the default zone selection based on the information we get from the browser, but currently ask the user to confirm it in all cases.
There are some libraries which try to deduce the time locale by testing the UTC offsets of a large number of historical points in time. For example, the UTC offset on June 13 at 1:15 PM in 1913 may differ between "America/Los_Angeles" and "America/Seattle", so by performing a bunch of tests like this at times when the locales are known to diverge, you can infer the locale name. However, this stuff all seemed big/complicated when I looked at it and didn't seem worth the external dependency.