Bug 1417516 - [RFE] Allow dashboard time zone to be user selectable
Summary: [RFE] Allow dashboard time zone to be user selectable
Alias: None
Product: ovirt-engine-dashboard
Classification: oVirt
Component: RFEs
Version: unspecified
Hardware: All
OS: All
Target Milestone: ---
: ---
Assignee: Vojtech Szocs
QA Contact: Pavel Novotny
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-30 03:16 UTC by Logan Kuhn
Modified: 2021-03-11 15:46 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-05-24 12:19:29 UTC
oVirt Team: UX
oourfali: ovirt-future?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)

Description Logan Kuhn 2017-01-30 03:16:59 UTC
Description of problem:
Currently the time zone for the dashboard plugin is locked to GMT and cannot be changed by the user.

Version-Release number of selected component (if applicable):

How reproducible: 100%

Additional info:
From a thread on the users mailing list: 
Dashboard relies on ECMA-402 Intl.DateFormat spec [1] or the Polyfill [2].  The spec says that implementations need to, at the very least, support 2 time zones.  First is 'undefined' and equates to the "runtime's default time zone".  Second is 'UTC'.  Since the first option is ambiguous and we don't know what it is unless we parse a formatted string, using a default of 'UTC' will provide the best cross-browser consistency.  Also, by forcing to a UTC TZ, everyone looking at times on dashboard, no matter where they are, will see the same times.

The Polyfill only supports the required 2 time zones.  See [3] for the gritty details of their implementation.

Additionally, each browser may or may not support named TZs at all for date formatting.  When I was trying to find a reasonable implementation to support time zone switching, there was little consistency across browsers (Firefox, Chrome, IE/Edge on Windows, Safari on Mac).  The Intl.DateFormat javascript support just doesn't cover the TZ problem very well.

There is another solution - re-implement dashboard's date formatting to use moment.js [4] and moment-timezone.js [5].  Doing so would let dashboard have a user selectable TZ, but would incur the cost of shipping moment's JS with locales (min-gz @ 67.9k) and timezones (min-gz @ 9.9k or 25.6k).  Wouldn't be difficult work.  It would just need to be given the green light.

TL;DR - Dashboard uses ECMA-402 and the spec doesn't require much TZ support for Intl.DateFormat.  Because browsers don't support formatting dates in different locales very well, UTC is used.  The safest way to support explicitly selected TZs right now is to swap the date formatting implementation out to one that uses momentjs.

[1] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat
[2] - https://github.com/andyearnshaw/Intl.js
[3] - https://github.com/andyearnshaw/Intl.js/blob/master/src/12.datetimeformat.js#L186
[4] - http://momentjs.com/
[5] - http://momentjs.com/timezone/


Comment 1 Greg Sheremeta 2017-03-13 14:23:04 UTC
I would say all times (not just in the dashboard) should render in the user's selected choice. Thoughts?

Comment 2 Logan Kuhn 2017-03-13 14:25:24 UTC
I concur.  It's probably in the top 5 wish list items for the oVirt UI for myself and company.

Ideally we'd have an option under either user > options so that it's selectable on an individual user basis or under configure and is global, or both and applies to the entire UI

Comment 3 Greg Sheremeta 2017-05-24 12:19:29 UTC
We improved the dashboard to use the user's time. Since we're no longer locked to GMT, and we don't have any use cases for a selectable TZ, closing.

Note You need to log in before you can comment on or make changes to this bug.