Created attachment 1090041 [details] schedule screenshot Description of problem: I have set a CFME database backup schedule. I can view it by navigating to Configure -> Configuration -> Settings accordion -> Schedules, I select the "DBBackup" schedule (see attached screenshot dbbackup-2.png). Next schedule is planned for 11/5 at 3:45 CET 2015. But if I edit the schedule (see attached screenshot dbbackup-3.png), it shows: Timezone: GMT+01:00 (Paris) Starting date: 11/5/2015 Starting time (Paris): 2h45mn The time is not Paris time, but GMT+00:00 time (the appliance timezone is GMT+01:00 (Paris)). If I cancel the edit without doing any change, and go back to the view, time is displayed correctly. (see attached screenshot dbbackup-4.png). Version-Release number of selected component (if applicable): 5.4.0.5.20150605150206_7daa1a8 How reproducible: Always Steps to Reproduce: 1. Configure -> Configuration, Settings accordion -> Schedules 2. Configuration -> Add a new schedule -> Select 'Database Backup' Action 3. Fill required details Timezone: GMT+01:00 (Paris) Starting date: 11/5/2015 Starting time (Paris): 3h45mn Save 4. Next schedule is planned for 11/5 at 3:45 CET 2015. 5. Now edit the same schedule, Starting time (Paris) shows GMT+00:00 time Starting time (Paris): 2h45mn Actual results: Starting time (Paris) shows GMT+00:00 time Expected results: Starting time (Paris) should show GMT+01:00 time which is 3h45mn in this case. Additional info: This is happening in all timezones except UTC.
Created attachment 1090042 [details] Edit schedule
Created attachment 1090043 [details] Cancel schedule
Hi Nikhil, I've tried to reproduce this in 5.5.z and have been unable to. Could you possibly provide any other details of your environment, and/or configuration if any changes were made? Thanks
Nikhil, I didn't see this at first, because it's already been fixed in https://github.com/ManageIQ/manageiq/commit/32b9cb23c0828f9daaff516d9cbec7e518bfa28d. It's now clear that this is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1274270, so I'll close this ticket. *** This bug has been marked as a duplicate of bug 1274270 ***