Page MenuHomePhabricator

Add support for setting the time zone of a program
Closed, ResolvedPublic3 Estimated Story Points

Description

Right now the start and end dates of a program are based on UTC midnight. We should allow program admins to set the time zone of their program so that the stats can be properly calculated based on the actual days in their location.

Current state:

calendar.jpg (651×1 px, 88 KB)

Wireframe with time picker and time zone:

Programs Dashboard Time picker new wireframe.jpg (608×1 px, 77 KB)

Event Timeline

DannyH triaged this task as Medium priority.Jul 26 2016, 12:18 AM
DannyH set the point value for this task to 3.Aug 23 2016, 5:41 PM
DannyH moved this task from To Be Estimated/Discussed to Estimated on the Community-Tech board.

Note:

In T125546#2611674, @Base wrote:
Don't know if it's worth mentioning but took a look at the design suggested and thought about it: start and end date/time are not always in the same timezone. Like CEE Spring in Ukraine this year started by EET (UTC+2) and finished by EEST (UTC+3) due to DST. So perhaps hidden by default but there should be a separate timezone field for the end point accessible too.

I worked with timezones and DST not too long ago on another project and it was a bit tricky. I think ideally the app should be intelligent about it and show the time as it would be currently, and once DST comes around it automagically updates. I believe this is how Google Calendar functions.

@DannyH Running into some UI problems:

Screen Shot 2016-10-04 at 1.47.09 PM.png (616×883 px, 64 KB)

I'm thinking the time zone dropdown should go on its own line. Alternatively, we could increase the overall size of the modal so everything would fit on one line, but we'd still have to add some media queries and show the timezone on its own line for users with smaller screens.

Note the times are dropdowns because this was significantly easier to implement, and we didn't have to worry about validations since they can only choose valid times. I'd prefer to stick with the dropdowns, but even if we changed it to a text field I think we'd still run into the issue of the timezone dropdown not squeezing in alongside it.

@MusikAnimal: How long is the longest time zone string?

@MusikAnimal: How long is the longest time zone string?

I'm not sure what we want. I assume just the two or three letter abbreviation (UTC, PT, EST)? If so the longest should be: "(GMT + 00:00) WWW". Of course there is not a WWW timezone, I don't think, only using W because it's the widest character

However, if we put the timezone on its own row we can use the full humanized time zone name. The strings are provided by Rails and I believe there are translations available: http://apidock.com/rails/v4.2.7/ActiveSupport/TimeZone

So like "(GMT + 04:00) Eastern Time (US & Canada)"

Putting on its own row seems like the best approach to me. And I'm all for getting free timezone i18n support... although I would be a little surprised if that worked out of the box with the javascript i18n scheme.

Putting on its own row seems like the best approach to me. And I'm all for getting free timezone i18n support... although I would be a little surprised if that worked out of the box with the javascript i18n scheme.

Ah, you're right that it's not so straightforward for JavaScript. We could interpolate the Rails timezone mappings into JS, but I think that might require the variable be bound to the global scope.

MusikAnimal: Yes, your solution looks great. Go for it. :)

Deployed to production :)