Bug 1420400
Summary: | Dashboard time zone should display current timezone instead of GMT | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Jason <jbryant> |
Component: | ovirt-engine-dashboard | Assignee: | Scott Dickerson <sdickers> |
Status: | CLOSED ERRATA | QA Contact: | Lucie Leistnerova <lleistne> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.1.0 | CC: | dornelas, gshereme, lsvaty, mkalinin, oourfali, sdickers, tjelinek |
Target Milestone: | ovirt-4.1.2 | Keywords: | ZStream |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-05-24 11:21:45 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | UX | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jason
2017-02-08 14:53:07 UTC
Hey. 1. If this is indeed the case, it should be a bug, not RFE. The dashboard should show LOCAL time. AFAIK, this is standard and expected behavior with any web app. 2. Second, I do not see where it is GMT. Mine shows local time. I have 4.0.4. Greg, What do you say? However, the customer confirms - they see it in GMT, despite being on CST. Greg, switching it to bug. Can you please help us understanding why it is not reproducible on our environments? IS there anything we can do to manually tweak it? From the customer: ~~~ From the manager's CLI: [root@rhevm] # date Tue Feb 7 10:41:45 CST 2017 From the dashboard page in the manager's UI: Last Updated 2/7/2017, 4:42:18 PM GMT ~~~ I think it's a bug and not an RFE. Assigning to Scott ... cc'ing Oved. In [1], Oved mentions things moving to UTC. I'm not aware of such an effort. [1] https://www.mail-archive.com/users@ovirt.org/msg38822.html Comment 3 on 1362402 [1] talks about the date/time format following the event log style. Selecting a TZ of UTC was a conscious choice following the same rationale and to provide consistent display across all users. We've had subsequent discussions and mails about TZ selection etc. All of those discussions funneled to an RFE BZ 1417516 [2]. So, UTC is what is currently expected to be formatted. In the future, it will most likely be an extra drop down on the login screen to select a TZ with either the browser default or UTC (depending on a system config) selected as default. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1362402#c3 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1417516 Scott, very interesting. However, what is not clear to me - why do we all see it here in our local environments as local time zone (EST, for example), but the customer sees GMT? Did this started happening from specific 4.0.z release? The bug you've pointed out to seem to be 4.1 only. Can you please help me understanding this? And if indeed I am seeing something wrong, and our environments are somehow wrong and the default behavior is GMT, then we should close this bug as duplicate of bz#1362402 and tell the customer it will be fixed soon in 4.1 GA. P.S. I believe customer is referring to the refresh time at the top left of the dashboard and not the tooltips that other bug is referring to. Here it is in customer's words: "Can the dashboard be manually refreshed? Also the logs are in CST. The "Last updated" time on the dashboard is GMT. Can that be changed to CST?" We'll sneak this into 4.1.1. @QE and PM, ack? It takes 1 minute to qa this change, and it's low risk. dashboard time changes according to local timezone verified in ovirt-engine-4.1.1.5-0.1.el7.noarch with ovirt-engine-dashboard-1.1.0-7.el7ev.noarch Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1278 |