Bug 1419150 - Retirement date/time always offsets 5 hours from GMT
Summary: Retirement date/time always offsets 5 hours from GMT
Status: CLOSED DUPLICATE of bug 1316632
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate
Version: 5.6.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: cfme-future
Assignee: Greg McCullough
QA Contact: Mike Shriver
Whiteboard: retirement:ec2
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-03 17:20 UTC by Mike Shriver
Modified: 2017-04-05 19:22 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-04-05 19:22:35 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:

Attachments (Terms of Use)
server settings (52.94 KB, image/png)
2017-03-09 22:21 UTC, Tina Fitzgerald
no flags Details
server settings (52.94 KB, image/png)
2017-03-09 22:23 UTC, Tina Fitzgerald
no flags Details

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):

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?


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

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

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?


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.

Can we close this as a duplicate?


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

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

Agreed on marking duplicate


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

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