| kaldari | |
| Jul 13 2016, 8:57 PM |
| F4556154: Screen Shot 2016-10-04 at 2.07.29 PM.png | |
| Oct 4 2016, 6:08 PM |
| F4556081: Screen Shot 2016-10-04 at 1.47.09 PM.png | |
| Oct 4 2016, 5:51 PM |
| F4289907: calendar.jpg | |
| Jul 20 2016, 12:10 AM |
| F4289910: Programs Dashboard Time picker new wireframe.jpg | |
| Jul 20 2016, 12:10 AM |
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:
Wireframe with time picker and time zone:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | MusikAnimal | T140801 Programs & Events Dashboard (tracking) | |||
| Resolved | MusikAnimal | T125546 Add support for start/end times in Programs Dashboard | |||
| Resolved | MusikAnimal | T140306 Add support for setting the time zone of a program | |||
| Open | None | T284752 Setting explicit time zone in Outreach Dashboard |
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:
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.
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.
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.
