Bug 1769333
| Summary: | Inconsistency in the time formats of Optimization Reports and Intel Reports | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Parthvi Vala <pvala> | ||||
| Component: | UI - OPS | Assignee: | Martin Hradil <mhradil> | ||||
| Status: | POST --- | QA Contact: | Sudhir Mallamprabhakara <smallamp> | ||||
| Severity: | medium | Docs Contact: | Red Hat CloudForms Documentation <cloudforms-docs> | ||||
| Priority: | medium | ||||||
| Version: | 5.11.0 | CC: | bmidwood, dmetzger, hkataria, lavenel, mhradil | ||||
| Target Milestone: | GA | ||||||
| Target Release: | 5.11.z | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | Type: | Bug | |||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | Feature | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | CFME Core | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
So I think this is a UI problem: https://github.com/ManageIQ/manageiq-ui-classic/pull/5819/files#diff-c5ed8fa4d4184cda2d95e7aa12924d21R27 Right,
* list views
* format "07/22/2019 9:44:50 am"
* formatted in JS, that `moment(date).format('MM/DD/YYYY h:mm:ss a')` line Drew has found (comment#2)
* detail view data
* format "03/08/18 17:34:52 UTC"
* come preformatted from the API (/api/results/20892?expand_value_format=true&hash_attribute=result_set)
* consistent with the new saved report view in Reports, the old view in Reports, list view in Reports
* detail view subheading
* format "Mon, 22 Jul 2019 09:44:45 +0000"
* formatted in ruby, `:timestamp => format_timezone(rr.created_on, Time.zone, "gt")` in ReportController::SavedReports
* consistent with other saved report screens
=> changing optimization list views to match the rest, switching to 24hour times with timezone info :)
Re timezones - API converts the dates to the timezone set in user settings, not browser timezone. So, to be consistent, the list view will have to ignore browser timezone and convert the dates to the user timezone. New commit detected on ManageIQ/manageiq-ui-classic/master: https://github.com/ManageIQ/manageiq-ui-classic/commit/7e83f20044f307782764cc62a66295229c81cbec commit 7e83f20044f307782764cc62a66295229c81cbec Author: Martin Hradil <mhradil> AuthorDate: Thu Nov 7 08:56:30 2019 -0500 Commit: Martin Hradil <mhradil> CommitDate: Thu Nov 7 08:56:30 2019 -0500 Optimization#show_list - use the same datetime conversion as the backend This makes sure that Optimization lists convert time to 24h, with time zone, the same format that's coming from /api/results/20892?expand_value_format=true&hash_attribute=result_set Previously, we would output show_list dates in the browser-local timezone, in 12h + am/pm format, now, we output all the dates in user-set timezone, 24h, including the timezone abbreviation. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1769333 app/javascript/optimization/transform.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) |
Created attachment 1633256 [details] Bug Demo Description of problem: There is a big inconsistency in the time formats for the reports generated on `Overview > Optimize` page and `Overview > Reports` page. Optimization reports use local timezone, while normal reports use the appliance timezone. Version-Release number of selected component (if applicable): 5.11 How reproducible: Always Steps to Reproduce: 1. Navigate to `Overview > Optimize` 2. Queue a report, wait until it finishes generating and note down the `Last Run at` value. 3. Navigate to `Overview > Reports > Saved Reports` or `Overview > Reports > Reports` and trace down the report generated in step 1. 4. Note the `Run At` value for the report traced in step 3 Actual results: 1. 2. Value for `Last run at` would be something like `11/06/2019 5:20:35 pm`. 3. 4. Value for `Run at` would be something like `11/06/19 11:50:35 UTC` Expected results: 1. 2. Value must correspond with `Run at` value. 3. 4. Additional info: IMO, using the format `11/06/19 11:50:35 UTC` would be better.