Bug 1419150

Summary: Retirement date/time always offsets 5 hours from GMT
Product: Red Hat CloudForms Management Engine Reporter: Mike Shriver <mshriver>
Component: AutomateAssignee: Greg McCullough <gmccullo>
Status: CLOSED DUPLICATE QA Contact: Mike Shriver <mshriver>
Severity: medium Docs Contact:
Priority: high    
Version: 5.6.0CC: duhlmann, gmccullo, hkataria, jhardy, mkanoor, mpovolny, mshriver, obarenbo, tfitzger
Target Milestone: GA   
Target Release: cfme-future   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: retirement:ec2
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-05 19:22:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
server settings
none
server settings none

Description Mike Shriver 2017-02-03 17:20:01 UTC 
Description of problem:

When selecting a retirement date in CFME 5.6.4, no time is selected only the date.

The specific retirement time is reported in the success flash message when the retirement date is set.

I'm observing retirement times of GMT-5 hours, with the default time being 00:00 on the selected date.

This means if I select a retirement date of 2/5/2017, the flash message and Lifecycle table will reflect a retirement date of 2/4/2017, at 19:00. This is 00:00 - 05:00.

The offset is not effected by the timezone setting for the appliance. By default the timezone was GMT, and after changing it to a different zone than GMT-5, the retirement date selection continued to offset the retirement by 5 hours.

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

How reproducible:
Every time a date is selected, regardless of appliance timezone configuration.

Steps to Reproduce:
1. Provision instance
2. Select retirement date for instance
3. Note flash message and Lifecycle table on instance summary reflect the day prior to the user selected date

Actual results:
Retirement is set to date prior to that selected by the user

Expected results:
Retirement date is set to the exact day the user selected.

Additional info:
Comment 6 Tina Fitzgerald 2017-03-09 22:21:51 UTC 
Created attachment 1261714 [details]
server settings
Comment 7 Tina Fitzgerald 2017-03-09 22:23:58 UTC 
Created attachment 1261716 [details]
server settings
Comment 8 Tina Fitzgerald 2017-03-09 22:27:34 UTC 
Hi Mike,

I attached a screen shot for my server settings. What are your settings for the Appliance Time Zone and Default Locale?

Thanks,
Tina
Comment 9 Mike Shriver 2017-03-14 17:21:00 UTC 
Tina,

The video that I posted in comment #4 (https://bugzilla.redhat.com/show_bug.cgi?id=1419150#c4) includes the settings page, showing:

Appliance Time Zone: UTC
Default Locale: Global Default
Comment 10 Mike Shriver 2017-03-14 17:24:27 UTC 
Tina,

Taking a bit closer look, the labels for the fields are different between your screenshot and the video that I took on CFME 5.6.4.  Not sure why that is, your screenshot doesn't match what I'm seeing in 56z or 57z
Comment 11 Tina Fitzgerald 2017-04-03 22:08:55 UTC 
Hi Mike,

I'm sorry I haven't gotten back to you sooner.

I spent some time looking into it today and although there are two places in the UI that specify the time zone, the display settings time zone(the setting from your video) is what changed the retirement date display value in my tests.
The retirement display date changed based on the settings, but the actual vm retirement date was correct. 

Can you setup an appliance where I can see the issue?

Thanks,
Tina
Comment 13 Mike Shriver 2017-04-05 13:32:54 UTC 
Responded with private comment including an appliance where the issue can be recreated. Appliance available for 7 days.
Comment 14 Tina Fitzgerald 2017-04-05 19:10:03 UTC 
Hi Mike,

I initially thought this was an Automate issue, but after further investigation, it looks like a UI issue.

UI issue reported against 5.6 and fixed in 5.7 and master.
https://bugzilla.redhat.com/show_bug.cgi?id=1316632

Can we close this as a duplicate?

Thanks,
Tina
Comment 15 Mike Shriver 2017-04-05 19:22:35 UTC 
Tina,

Jeff's BZ 1316632 captures the behavior sufficiently, especially if linked with my description here.

Agreed on marking duplicate

Thanks,
Shriver

*** This bug has been marked as a duplicate of bug 1316632 ***