Bug 1654749 - Retirement date of a VM is not internationalized
Summary: Retirement date of a VM is not internationalized
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - OPS
Version: 5.9.5
Hardware: x86_64
OS: Linux
Target Milestone: GA
: cfme-future
Assignee: Josh Carter
QA Contact: Sudhir Mallamprabhakara
Red Hat CloudForms Documentation
Depends On:
TreeView+ depends on / blocked
Reported: 2018-11-29 15:18 UTC by cparent
Modified: 2019-06-11 15:26 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-06-11 15:26:24 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:

Attachments (Terms of Use)
VM lifecycle information, with the 2 dates formats (7.02 KB, image/png)
2018-11-29 15:58 UTC, cparent
no flags Details

Description cparent 2018-11-29 15:18:41 UTC
Description of problem:

When setting a retirement date on a VM, the date always appears in the MM/DD/YY format. This is different from the creation date of the same VM, which uses a non ambiguous international format.

Retirement date: 12/03/18 01:00 CET
Created On: Mon, 26 Nov 2018 16:26:55 +0100

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

How reproducible:

Steps to Reproduce:
1. Set a Retirement date on a VM
2. Display the VM details

Actual results:
Retirement date is confusing for non US users and shoud use a non ambiguous format.

Expected results:
Retirement date use the same format of creation date

Additional info:

Comment 3 cparent 2018-11-29 15:58:51 UTC
Created attachment 1509863 [details]
VM lifecycle information, with the 2 dates formats

Comment 5 Milan Zázrivec 2018-11-30 11:22:18 UTC
The dates shown on summary screens *are* localized, since those are all read-only
screens and rendering localized dates there is quite simple.

Nevertheless, dates shown in our forms (datepicker, datetimepicker) are not localized
and always default to MM/DD/YYYY format.

There's no easy way to implement what's requested here, since:
* there's a substantial amount of forms in our application with datepicker
* we have angular / non-angular forms (i.e. implementations are different)
* we cannot simply fix one form and leave the others non-localized (this is
not possible from technical point of view, nor from product point of view)

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