Why don't you want to change your timezone?

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.

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)

"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.

In T11141#180280, @epriestley wrote:

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.

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.

In T11141#180288, @epriestley wrote:

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.

In T11141#180290, @epriestley wrote:

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.