Render timezones explicitly in email
Closed, ResolvedPublic
Actions

Assigned To

None

Authored By

	eadler
	Mar 21 2016, 4:09 PM

Description

On our internal phabricator I created a countdown where the transaction correctly says
eax updated this countdown to end on Mon, Mar 21, 9:30 AM. [in PST]
I got an email
eax updated this countdown to end on Mon, Mar 21, 4:30 PM.

metamta.one-mail-per-recipient is on

Revisions and Commits

rP Phabricator
	D16287	rP26c6f64fd469 In email, render dates with an explicit timezone offset
	D16286	rP7b09f5698fe0 Convert Calendar to Modular Transactions

Related Objects

Mentioned Here: D16287: In email, render dates with an explicit timezone offset
T9275: Move Calendar to EditEngine
T9854: Support date/time reformatting in Remarkup
T3025: Detect when browser and account timezone settings differ and prompt user to reconcile them

Event Timeline

eadler created this task.Mar 21 2016, 4:09 PM

eadler updated the task description. (Show Details)

With metamta.one-mail-per-recipient on, we can adjust this to the viewer's preferences.

With metamta.one-mail-per-recipient off, probably using the server default and showing the timezone in the mail explicitly is the best option.

We don't currently distinguish between these cases very carefully because we don't have many other transactions where rendering is a function of the viewer, but will have these more prominently in Calendar in the future.

It might not be bad to always show timezones in email explicitly to deal with cases related to T3025 better (e.g., you fly to the east coast for a conference, get prompted to reconcile your timezone after T3025, and it may not be obvious that this also affects mail you receive until you return and re-reconicle back to PST).

eadler updated the task description. (Show Details)Mar 21 2016, 4:16 PM

I think this isn't tremendously important for Countdown but should definitely be sorted out before we unbeta Calendar.

You can probably mitigate it by setting the server timezone to wherever most of your users are (you can do this with phabricator.timezone in Phabricator config, or date.timezone in PHP config, without actually needing to change the OS-level settings).

epriestley moved this task from Backlog to Unprototype (v1) on the Calendar board.Mar 21 2016, 4:41 PM

epriestley renamed this task from countdown email does not honor timezone preferences to Render timezones explicitly in email.Apr 6 2016, 3:27 PM

T9854 is also vaguely related, but fairly separate.

I think the plan here is:

Introduce a renderDate() helper for PhabricatorModularTransactionType, similar to the existing renderAuthor() and renderObject() helpers.
Have that render with timezones when targeting an email context.
So, we're blocked on T9275.

Subproblem:

We don't have a standard list of timezone codes from locale codes, and one might (?) not really exist (?).
For example, we can render "9:00 AM (America/Los_Angeles)" or "9:00 AM (UTC-7)" but have no mapping from either of those to a timezone code like "PST" / "PDT". Using UTC-offset wouldn't be terrible for v1, though.

epriestley added a revision: D16286: Convert Calendar to Modular Transactions.Jul 12 2016, 11:19 PM

epriestley added a commit: rP7b09f5698fe0: Convert Calendar to Modular Transactions.Jul 13 2016, 2:46 PM

epriestley added a revision: D16287: In email, render dates with an explicit timezone offset.Jul 13 2016, 2:52 PM