Page MenuHomePhabricator

Render timezones explicitly in email
Closed, ResolvedPublic


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. is on

Event Timeline

eadler updated the task description. (Show Details)
eadler updated the task description. (Show Details)
epriestley triaged this task as Wishlist priority.Mar 21 2016, 4:13 PM
epriestley added a subscriber: epriestley.

With on, we can adjust this to the viewer's preferences.

With 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).

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


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

I've marked D16287 as fixing this, although it does not fix Countdown (today, only Calendar has the new behavior).

Countdown will pick up this new behavior automatically when it is converted to Modular Transactions.

D16287 doesn't implement timezone short codes, we can deal with that as it arises.