Bug 1558628

Summary: Automate Schedule: "Starting time" field saves nonsense.
Product: Red Hat CloudForms Management Engine Reporter: Milan Falešník <mfalesni>
Component: UI - OPSAssignee: Dan Clarizio <dclarizi>
Status: CLOSED DUPLICATE QA Contact: Dave Johnson <dajohnso>
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.9.0CC: hkataria, lavenel, mpovolny, obarenbo
Target Milestone: GA   
Target Release: cfme-future   
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: 2018-03-20 16:37:17 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:

Description Milan Falešník 2018-03-20 16:04:33 UTC
Description of problem:
When I want to schedule an automate task and specify its starting hour, it behaves weirdly and stores either curret time or 01:00 (assuming midnight given my location has +1).

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

How reproducible:
always

Steps to Reproduce:
1. Go to Configuration / Schedules and create a simple Automation Task schedule. You can try both Once and Hourly, it does the same. Make sure you set the time to the future, pick eg. 22:45
2. After save, you can see the current time got saved instead of the selected one.
3. Try editing the schedule, you can see the time of creation in there. Notice that if you did not make the creation on a minute divisible by 5, the minute dropdown says Nothing selected.
4. Now, select a proper future time again (eg. 22:15). Save the schedule.
5. Look at the schedule now, the time is 01:00 (00:00 UTC, I am +1).

Actual results:
Times set wrong

Expected results:
Times set correctly.

Additional info:
It looks like the other kinds of schedules are not affected, I tested the Compliance ones and they seem to work fine.

Comment 2 Milan Falešník 2018-03-20 16:37:17 UTC
Somehow this got created twice ...

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