Page MenuHomePhabricator

"Adjust timezone" dialog does not default to "ignore" in Chrome
Open, Needs TriagePublic

Description

Reproduction steps (on current secure.phabricator.com version):

  1. Set your account timezone location to something (my case: Los Angeles a.k.a. San Francisco)
  2. Set your machine's timezone location to something different (my case: London whilst on business trip)
  3. Get an annoying "Your browser timezone setting differs…" prompt on every page.
  4. Click it hoping to tell it to ignore, but find no ignore button.
  5. Eventually accept that you have to change it, open the "New Setting" timezone location drop-down to change you preference; find "Ignore Conflict" in the list, despite it not being a place, nor a conflict.

Expected outcome:

  • Change dialog should have a button saying "ignore difference" (or maybe "…conflict" though that word is confusing and doesn't match the wording in the warning banner) next to the "Cancel" and "Change Timezone" buttons), and not mix UI metaphors and hide the most likely user outcome control.

Event Timeline

Why don't you want to change your timezone?

chad renamed this task from "Adjust timezone" dialog has some poor UX issues to "Adjust timezone" dialog doesn't have a way to cancel/ignore.Jun 13 2016, 7:20 PM

Or, perhaps more specifically: why do you want to change your machine's local timezone, but not change Phabricator's timezone to be consistent? If you just didn't want to change your timezone at all, you could leave everything in PST while in London and your system clock and Phabricator would both remain in PST, but you did change your system clock.

vinzent added a subscriber: vinzent.EditedJun 13 2016, 7:21 PM

why not using the browsers timezone by default and giving the possibility to set a static one in the settings if really required (without this message popping up)

chad edited projects, added Feature Request; removed Bug Report.Jun 13 2016, 7:22 PM

"Adjust timezone" dialog doesn't have a way to cancel/ignore

This isn't accurate -- there's an "Ignore" in the dropdown. This is described in step (5).

This is the default selection in browsers which do not give us a way to identify the current locale (today, Safari and Firefox).

The current locale is the default selection in browsers which do (today, Chrome). In the steps above, I would expect the dropdown to have defaulted to "Europe/London".

why not using the browsers timezone by default and giving the possibility to set a static one in the settings if really required (without this message popping up)

  • We can not identify the browser's timezone reliably in most browsers (only the UTC offset).
  • We can't easily "fix" the content of a page if we serve it in one timezone and then discover that your client is in a different timezone.
  • Users tend to find implicit magic like this confusing and often want more explicit control over settings and behavior.

Or, perhaps more specifically: why do you want to change your machine's local timezone, but not change Phabricator's timezone to be consistent? If you just didn't want to change your timezone at all, you could leave everything in PST while in London and your system clock and Phabricator would both remain in PST, but you did change your system clock.

No, I moved and my system clock represents both local time (auto-adjusted based on location) and about a half dozen other timezones in a rotating clock at the top of my screen.

I was half-tempted to put this in as a feature request, but given that I complained about this mis-feature to six different people before one of them worked out how to use it I guesstimated that the UX issue was severe enough to call a bug. Happy to be over-ruled.

epriestley renamed this task from "Adjust timezone" dialog doesn't have a way to cancel/ignore to "Adjust timezone" dialog does not default to "ignore" in Chrome.Jun 13 2016, 7:25 PM

auto-adjusted based on location

If you auto-adjust the primary local time displayed on your system, why don't you also want to adjust Phabricator?

We pop this dialog because your browser's time (which only has one time, and which is the only time we can see) has changed.

auto-adjusted based on location

If you auto-adjust the primary local time displayed on your system, why don't you also want to adjust Phabricator?
We pop this dialog because your browser's time (which only has one time, and which is the only time we can see) has changed.

And so, it also does so when I use a machine in a random Internet café in Egypt, when my phone notices I'm very close to the Arizona/California border (except during Summer Time), when I live in Eastern Oregon but I work in the centre of the state, …

I think the idea that users explicitly set a timezone location, and that it's a constant which is actively changed by the user, is too simple.

Is the behavior you want the same as @vinzent's desired behavior, your phone's behavior, and your laptop's behavior? That is, blindly trust client timezone unconditionally, without prompting or notifying you? From the original description, it seemed like you wanted essentially the opposite behavior.

what do others do about that timezone thing? I'm not aware that i needed to specify a timezone on other services.

I was just looking at github settings - could not find a timezone config. and I don't remember setting any timezone in Stash (bitbucket).

how do they know which timezone to use in the frontend?

GitHub does not appear to ever render absolute time. Instead, it renders relative times like "5 hours ago", etc.

Bitbucket does not appear to ever render absolute time, either. Instead, it renders only dates.

We can't do this in Phabricator because applications like Calendar rely on time, and specifically rely on absolute time. These solutions ("never render times") are also clearly worse than rendering absolute time correctly. I suspect both applications get dates wrong when different locales in the same UTC offset would produce different results, although these cases are rare.

Bitbucket corrects dates based on the client UTC offset on the client after rendering them (if you disable Javascript, your browser will display the wrong dates).

GitHub corrects dates on the server side based on setting a tz cookie. The first page you load in a new timezone is wrong. Reloading the page corrects it.

Is the behavior you want the same as @vinzent's desired behavior, your phone's behavior, and your laptop's behavior? That is, blindly trust client timezone unconditionally, without prompting or notifying you? From the original description, it seemed like you wanted essentially the opposite behavior.

Yeah, for MediaWiki we have a server default (normally UTC for Internet-facing wikis, except for localised instances) and then individual accounts can vary from that, but the expectation is that the vast majority of users just use and get used to UTC. I like how Phab tries to go better than this, but it feels not quite right now.

As you say, relative times are nice where you can put them in, but it's not compatible with some applications (like calendaring) and can be quite constrictive even outside that.