Page MenuHomePhabricator

Detect when browser and account timezone settings differ and prompt user to reconcile them
Closed, ResolvedPublic

Description

When the user's client-side timezone settings differ from the user's server-side timezone settings, we should prompt them to reconcile the discrepancy. The option in Settings is easy to miss, not very convenient when you travel, and client timezone settings are probably trustworthy most of the time for Phabricator users.


Original Description

The timestamps are all in Pacific time. It'd be better to convert them to the user's time (according to their browser's timezone report), but we should at least say "GMT-8" or "PST" or something in our timestamps.

Event Timeline

What is your Timezone set to in Settings -> Account?

Didn't know that even existed, sorry. I still think it's not really right, though, to -quietly- trust a setting when the browser report disagrees. So ideally, this task would be to 1) add the timezone to the timestamps and 2) make it clickable to change it if you think it is whack.

Would "detect when the user setting differs from the browser setting and prompt the user to reconcile them" be OK? e.g., something like a notification in the lower left corner that says:

Your client timezone is GMT+3, but your account
timezone is GMT-8. Dates and times will be show
in GMT-8.
                          Edit Setting • Ignore

Or maybe "Use GMT+3 • Edit Setting • Ignore". But generally I think browser settings aren't especially trustworthy either -- probably better for Phabricator users than Facebook users, but we've had at least 3-4 people come into IRC hitting timestamp skew issues with request signing and have difficulty setting their system clocks correctly. Basically, I'd like to fix the quiet/implicit part of this but leave the account setting as the primary authority.

Gotcha. Yeah, I think that's reasonable.

So mine would go from

Via Web · Fri, Apr 19, 9:22 AM

to

Via Web · Fri, Apr 19, 9:22 AM GMT+7 • Use GMT+1

then when I was back in SF it would be

Via Web · Fri, Apr 19, 9:22 AM GMT+7

...I don't think we really need an edit / ignore since it's almost certain that either the set time or the browser time is correct. In such a case, they can go to their settings page on their own...

I probably wouldn't put this in the actual timestamps but in some kind of UI element, but it sounds like we're more or less on the same page.

epriestley renamed this task from Phabricator's timezones are inexplicit in their Bay-area-centricity to Detect when browser and account timezone settings differ and prompt user to reconcile them.Apr 19 2013, 4:40 PM
epriestley triaged this task as Low priority.
epriestley updated the task description. (Show Details)
epriestley added a project: Phabricator.

sweet. I think it'd be good to always have the timezone in the actual timestamp, though. But not a biggie.

epriestley added a subscriber: Unknown Object (MLST).Sep 3 2013, 11:43 PM

Via FB.

chad lowered the priority of this task from Low to Wishlist.Nov 3 2014, 2:23 AM
chad edited projects, added User Preferences; removed Phabricator.
chad changed the visibility from "All Users" to "Public (No Login Required)".
eadler added a project: Restricted Project.Apr 19 2016, 5:32 AM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 19 2016, 5:32 AM

FWIW, from our perspective we really want the time zone to be correct (for our users) by default without any manual intervention. From the discussion above, it seems like this ticket is leaning towards a scheme were the user is expected to set their time zone in Phabricator, but displaying a recon dialog if it mismatches the browser.

While I get that for browsers "in the wild", it's not always feasible to assume the client setting is correct - what do you think about supporting a mode that always uses the client (browser) timezone by default without any manual action taken by the user?

In our case all clients are expected to have a correct time of day or plenty things break; and if the time zone is actually wrong it's totally fine for us to have the user stop doing whatever strange thing their doing to have an incorrect time zone.

To support the concerns discussed above, can I suggest a setting which allows picking one of:

  • Respect browser timezone.
  • Ignore browser timezone.
  • Use server setting, warn user on discrepancy.

Alternatively if only the latter two are available - is the intent that the "Ignore" is permanently (e.g. not just for the duration of the browser setting) persistent if clicked?

what do you think about supporting a mode that always uses the client (browser) timezone by default without any manual action taken by the user?

We could give users three options:

  • Always respect browser setting.
  • Prompt when browser setting differs.
  • Never respect browser setting.

I don't want to make "Always" the upstream default, but after T4103 you could make it the local default.

If you have "prompt" configured and click a one-time ignore, I'd expect it to ignore the discrepancy only until the timezone changes again. Selecting "never respect browser setting" would disable the behavior forever.

eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.May 21 2016, 4:04 PM

D15961 adds a timezone correction workflow, including a temporary "ignore conflict" option. This flag is cleared after the next timezone change.

Two possible areas for future work:


This doesn't add an "Always trust browser" option. This is a bit tricky because we do timezone stuff on the server, but can't detect the client timezone there. By the time we have the opportunity to detect the client timezone we may already have served a page, complete with times rendered in the wrong timezone.

In some cases, we could just reload the page and users probably wouldn't catch it, but in other cases this could destroy data (e.g., you type up a task while crossing into mountain time on the transcontinental Hyperloop, and submit it in a different timezone than you started). This class of cases is tractable but the workflow as implemented seems lightweight enough that I'd like to avoid building this if we don't really need it.

We could also do things like correct the timezone on login, but Phabricator sessions are generally long-lived and likely to survive transit across timezones.

Or we could autocorrect the timezone lazily and just trust users not to notice the first page load, but this isn't great if you arrive in New York, click a link in your email to pull up an event you need to attend, and are given the incorrect time without notice.

It's also possible we could move all time rendering to the client, so the page would just update in realtime if you swapped timezones. This is probably a relatively enormous amount of work, though.


Second, the locale selector prompts users with a relatively overwhelming number of options, particularly in GMT-4 (Eastern Time). It might be nice to rank the 2-3 most populated locales first in a "Common Timezones" group, then put the rest in an "Other Timezones" group. For example, GMT-7 (Pacific) currently lists these options:

America/Creston
America/Dawson
America/Dawson_Creek
America/Hermosillo
America/Los_Angeles
America/Phoenix
America/Santa_Isabel
America/Tijuana
America/Vancouver
America/Whitehorse

It could list them like this instead:

Common Timezones
  America/Los_Angeles
  America/Phoenix
  America/Vancouver
Other Timezones
  America/Creston
  America/Dawson
  America/Dawson_Creek
  America/Hermosillo
  America/Santa_Isabel
  America/Tijuana
  America/Whitehorse

Firefox and Chrome also support Intl.DateTimeFormat().resolvedOptions().timeZone which we could use to pre-select a timezone. I haven't implemented support for that yet.

D15962 attempts to guess the user's timezone by using the Intl API. This appears to be very accurate in Chrome on OSX, but useless in Safari/Firefox.

Another solution to this is something like jsTimezoneDetect which guesses the timezone by empirically testing how the time is rendered locally at "interesting" points in history (where different timezones with the same GMT offset today would have differed, e.g. immediately before/after daylight savings time).

Moment Timezone does something similar, and also includes a sort by population to try to guess the most likely candidate among otherwise indistinguishable zones.

My inclination is that this increased granularity is likely not worth the complexity, but these are possible avenues we could pursue.

These changes are now live on this install.

Two example ways to experience them for yourself:

  • Go to SettingsDate and Time in Phabricator, change your "Timezone" to something exotic, reload the page.
  • Go to your local machine's system settings, change your timezone to something exotic, reload the page.

D15961 has some screenshots of the workflow.

Particularly in Chrome (where we can prefill the correct timezone using Intl) this workflow feels lightweight / not-annoying to me even without an "Always Trust Client" setting. This setting creates some technical hurdles (see above) and would probably not be of much use until T4103 anyway, so I don't have any immediate plans to pursue it. Tentatively, I'd plan to look at whatever feedback we've received about this after shipping T4103 and make a decision then about adding more settings.

I'm pausing this for feedback since I think it's in reasonable shape as-is.


GoalRefTimeNotes
Reconcile Client TimezonesD159610.5 HoursPrompt users to reconcile mismatched client/server timezone settings.
Use Intl APID15962-Guess timezone in Chrome using Intl API.
Subtotal0.5 Hours
Cumulative Total0.5 Hours

I tried it out. One thing I realized was that without having the context of this ticket, during the pop-up after you click the notification, it's not obvious whether the timezone being shown is the *current* setting or the *new setting based on your browser*. That could cause confusion, so would suggest a slight phrasing change there.

Perhaps "The time zone selected below has been auto-detected based on your browser settings. To change your time zone to this value, click submit"?

Couple of other things that aren't necessarily actionable but wanted to mention them:

  • It took me a bit to find the pop-up. I realized it was probably because I've learned to mostly ignore them, which probably suggests I should turn them off for my user.
  • There was no explicit prompt indicating that I can click the notification to take action. I'm not sure, but I imagine some folks could not realize this is possible.

The time zone selected below has been auto-detected based on your browser settings

This is unfortumately only true some of the time (basically, in Chrome). I made some other adjustments in D15965 to try to make the behavior of the workflow more clear:

  • Show current setting explicitly.
  • Label new setting as "new setting".
  • Change button text to "Change Timezone".

Here's an example:

I added a "..., click to reconcile." call to action to the bubble as well.

On visibility, we can make the bubble bounce or spin or flash or something but I think visibility is pretty good already for most users.

That's a lot more clear, thanks!

Could we special case UTC, with a custom message and simpler "no change" process?

I'm not sure I understand the use case for that. Do you set your client OS to local time, but prefer to use Phabricator in UTC? Offhand, this seems unusual. Do you have any particular reason for doing this (e.g., you live right next to a timezone boundary and change zones multiple times per day)?

I also don't understand how the "no change" process could be meaningfully simpler, assuming you mean "ignore the discrepancy". You click the yellow button, and "Ignore" should be selected by default most of the time (although this depends on the browser). I'd expect the need to reconcile to be extremely rare (maybe a few times a year for daylight savings / travel?) and almost always useful to almost all users. Are you seeing a more involved process? How do you imagine it working instead?

We also can't detect UTC on the client in some browsers, as distinct from other UTC+0 locales (the only thing we can read in every browser is the offset from UTC, not the actual timezone), although it sounds like you probably use local time in your browser so this isn't an issue here.

We could do something like "if the server timezone is set to UTC explicitly, never prompt users to reconcile timezones", but this feels a bit weird/magical to me. I'd rather add an explicit "never prompt me" setting than make UTC have this implicit behavior, but I'd like to see a broader interest in this before building it (see also T8227).

My device is part of my life based in a real timezone. My OSS development and other intensive online community activity occurs in UTC, to simplify my mental calculations about other people's current time and aiding communication of timestamps and deltas.

It is a pop up , and in the case of UTC it is asking something silly.
UTC is not a timezone people live in.

Hit by this again on a trip to a nearby country. Can the "Ignore Conflict" option be moved out of the list so the user doesnt have to click "Save Timezone" to in fact register they want no change. I instinctively want to hit the Cancel button on this popup/overlay, as I dont want to change my timezone. I just want the message to stop.

I saved "Ignore Conflict" here and on phabricator.wikimedia.org , but a few hours later the warning message overlay has reappeared. Im going to ignore it here, so that the devs can see when I last saved "Ignore Conflict".

I saved "Ignore Conflict" here and on phabricator.wikimedia.org , but a few hours later the warning message overlay has reappeared. Im going to ignore it here, so that the devs can see when I last saved "Ignore Conflict".

Ah, the problem is I have multiple devices, and not all of them are set to switch timezone automatically, so Phabricator keeps believing it has seen me switch timezones, when I have switched devices/browsers with different timezones.
All the while, I have set my Phabricator timezone to be timezone agnostic, which is being ignored.

epriestley claimed this task.

This appears functional and is now accounted for.

See T11141 for followups around unusual use cases.