[ovirt-users] Change the timezone on the dashboard

[Logan Kuhn]

So should I put in an RFE for user selectable time zone?

Logan

On Sat, Jan 28, 2017 at 3:24 PM, Scott Dickerson <sdickers at redhat.com>
wrote:

>
>
> On Sat, Jan 28, 2017 at 12:06 AM, Oved Ourfali <oourfali at redhat.com>
> wrote:
>
>> This is not possible at the moment.
>> We had difficulties trying to get the one defined by the browser as well.
>> As we go towards having all logs and audit to UTC in 4.2 the latest, for
>> log aggregation purposes, we might not invest time in that as well.
>>
>> However, perhaps it can be easy to set this up in the ui plug-in
>> definition. It will require manually editing the file, but it is a valid
>> workaround.
>>
>> Scott / Vojtech, your thoughts?
>>
>
> 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/
>
>
> Regards,
> Scott
>
>
>> Thanks,
>> Oved
>>
>> On Jan 27, 2017 19:01, "Logan Kuhn" <support at jac-properties.com> wrote:
>>
>>> Is there a way to change the timezone for the dashboard plugin?
>>>
>>> I've searched the list and the plugin files and can't seem to find where
>>> it's set.
>>>
>>> Logan
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>
>
> --
> Scott Dickerson
> Senior Software Engineer
> RHEV-M Engineering - UX Team
> Red Hat, Inc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170129/21b7dd41/attachment.html>