Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1335133

Summary: Unnecessary date/time transformation for sync plan start date
Product: Red Hat Satellite Reporter: Oleksandr Shtaier <oshtaier>
Component: WebUIAssignee: Walden Raines <walden>
Status: CLOSED ERRATA QA Contact: Lukas Zapletal <lzap>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.2.0CC: andrew.schofield, bbuckingham, lzap, sthirugn, walden
Target Milestone: UnspecifiedKeywords: Regression, Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
URL: http://projects.theforeman.org/issues/15180
Whiteboard:
Fixed In Version: rubygem-katello-3.0.0.44-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1339650 (view as bug list) Environment:
Last Closed: 2016-07-27 11:04:14 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:
Bug Depends On: 1339650    
Bug Blocks:    
Attachments:
Description Flags
Sync plan works
none
Sync plan works none

Description Oleksandr Shtaier 2016-05-11 12:19:42 UTC 
Description of problem:
From first glance, transforming date and time for sync plans to Satellite server values can be treated as a feature, but is unacceptable from user perspective. That is fine to have some logic like this, but somewhere internally on the server, not for public view

API example:
Making HTTP POST request to https://server/katello/api/v2/organizations/1850/sync_plans with options {'verify': False, 'auth': ('admin', 'changeme'), 'headers': {'content-type': 'application/json'}} and data {"interval": "hourly", "enabled": false, "organization_id": 1850, "sync_date": "06/07/2372 04:18", "name": "name"}.

Received HTTP 200 response:   {"id":132,"organization_id":1850,"name":"name","description":null,"interval":"hourly","next_sync":null,"created_at":"2016-05-11 10:48:20 UTC","updated_at":"2016-05-11 10:48:20 UTC","enabled":false,"products":[],"permissions":{"view_sync_plans":true,"edit_sync_plans":true,"destroy_sync_plans":true},"sync_date":"07/06/2372 12:18:AM"}

UI example:
Created with '2016-05-11' and '15:09'
and received:
'05/11/2016 08:09:AM'

If API part has not so serious impact, but UI behaviour should be definitely treated as severe issue as for user it is complete mess why his data is transformed in that way.

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

How reproducible:
Always

Steps to Reproduce:
1. Create new sync plan with specific start data and time
2. Read the entity back and check the values returned
3.

Actual results:
Data and time is transformed to system time taken from the server where application is deployed

Expected results:
Data and time should be shown in the same format and values as user inputted them

Additional info:
'Start Date' is transformed, but not the 'Next Sync' information that is add even more chaos in sync process
Comment 1 Oleksandr Shtaier 2016-05-11 12:21:25 UTC 
Blocker for bunch of test automation cases
Comment 3 Oleksandr Shtaier 2016-05-11 14:40:54 UTC 
Regression was introduced pretty recently (I suspect in first GA) as automation started to fail just for last build for that area
Comment 4 Walden Raines 2016-05-12 15:02:17 UTC 
*** Bug 1317951 has been marked as a duplicate of this bug. ***
Comment 5 Walden Raines 2016-05-12 15:02:26 UTC 
*** Bug 1317681 has been marked as a duplicate of this bug. ***
Comment 6 Walden Raines 2016-05-12 15:02:31 UTC 
*** Bug 1317675 has been marked as a duplicate of this bug. ***
Comment 7 Walden Raines 2016-05-25 14:14:33 UTC 
Created redmine issue http://projects.theforeman.org/issues/15180 from this bug
Comment 8 Walden Raines 2016-05-25 15:49:52 UTC 
Currently we are storing sync plan times in the server's local timezone.  This means that if the server changes timezone (even just for daylight saving time) then the sync plan's time could be incorrect.

We need to either migrate the katello_sync_plans.sync_date column to a datetime with timezone or convert all rows to UTC (I prefer the latter).  We should be storing and returning these dates as UTC and formatting them client side with the client's local timezone.  This would eliminate confusion as to what timezone the next sync and sync date times are referring to.

In addition to the above the fix for this bug will requires an AngularJS upgrade in order to display times in the correct timezone (see [1] and [2]).  

We will need to decide if fixing this for 6.2 is worth the risk of the data migration and an AngularJS upgrade.  We would want to retest all of the Katello UI and especially sync plans to be sure the upgrade doesn't break anything.

[1] https://github.com/Katello/bastion/pull/112
[2] https://github.com/Katello/katello/pull/6056
Comment 9 Bryan Kearney 2016-05-25 16:16:32 UTC 
Upstream bug component is WebUI
Comment 10 Walden Raines 2016-05-25 17:39:14 UTC 
*** Bug 1339650 has been marked as a duplicate of this bug. ***
Comment 11 Bryan Kearney 2016-05-25 18:17:33 UTC 
Upstream bug component is Uncategorized
Comment 12 Walden Raines 2016-05-26 20:36:52 UTC 
PR: https://github.com/Katello/katello/pull/6079
Comment 13 Bryan Kearney 2016-05-26 22:17:30 UTC 
Upstream bug component is WebUI
Comment 14 Walden Raines 2016-06-03 16:11:07 UTC 
See also bug #1342603 when testing this bug.  Note that bug #1342603 prevents you from changing from "Browser Timezone" to a set timezone and then back to "Browser Timezone".
Comment 15 Bryan Kearney 2016-06-03 20:16:02 UTC 
Moving to POST since upstream bug http://projects.theforeman.org/issues/15180 has been closed
Comment 16 Lukas Zapletal 2016-06-22 08:53:03 UTC 
Created attachment 1170638 [details]
Sync plan works
Comment 17 Lukas Zapletal 2016-06-22 08:53:23 UTC 
Created attachment 1170639 [details]
Sync plan works
Comment 18 Lukas Zapletal 2016-06-22 10:02:55 UTC 
On SNAP 17 server created a plan with time 13:13. It was shown properly, then I changed the timezone and the plan was presented correctly in the UI.

Hit the bug #1342603 which was ignored.

Verified the sync plan actually started on time.

The CLI is still presented in UTC, but this was not part of the fix. VERIFIED

[root@hp-dl360g7-01 ~]# hh sync-plan list --organization MyOrg
---|---------------|---------------------|----------|--------
ID | NAME          | START DATE          | INTERVAL | ENABLED
---|---------------|---------------------|----------|--------
1  | Test timezone | 2016/06/22 09:00:00 | daily    | yes    
---|---------------|---------------------|----------|--------
[root@hp-dl360g7-01 ~]# date
Wed Jun 22 10:46:50 CEST 2016
[root@hp-dl360g7-01 ~]# hh repository info --organization MyOrg --name ZooRepo --product TestProduct
ID:                 1
Name:               ZooRepo
Label:              ZooRepo
Organization:       MyOrg
Red Hat Repository: no
Content Type:       yum
Checksum Type:      sha256
URL:                https://repos.fedorapeople.org/repos/pulp/pulp/demo_repos/zoo/
Publish Via HTTP:   yes
Published At:       http://hp-dl360g7-01.lab.eng.brq.redhat.com/pulp/repos/MyOrg/Library/custom/TestProduct/ZooRepo/
Relative Path:      MyOrg/Library/custom/TestProduct/ZooRepo
Download Policy:    on_demand
Product:            
    ID:   1
    Name: TestProduct
GPG Key:            

Sync:               
    Status:         Success
    Last Sync Date: about 8 hours
Created:            2016/06/22 03:10:53
Updated:            2016/06/22 03:11:12
Content Counts:     
    Packages:       32
    Package Groups: 2
    Errata:         4

[root@hp-dl360g7-01 ~]# rpm -q satellite katello foreman
satellite-6.2.0-17.0.el7sat.noarch
katello-3.0.0-8.el7sat.noarch
foreman-1.11.0.39-1.el7sat.noarch
[root@hp-dl360g7-01 ~]# hh repository info --organization MyOrg --name ZooRepo --product TestProduct
ID:                 1
Name:               ZooRepo
Label:              ZooRepo
Organization:       MyOrg
Red Hat Repository: no
Content Type:       yum
Checksum Type:      sha256
URL:                https://repos.fedorapeople.org/repos/pulp/pulp/demo_repos/zoo/
Publish Via HTTP:   yes
Published At:       http://hp-dl360g7-01.lab.eng.brq.redhat.com/pulp/repos/MyOrg/Library/custom/TestProduct/ZooRepo/
Relative Path:      MyOrg/Library/custom/TestProduct/ZooRepo
Download Policy:    on_demand
Product:            
    ID:   1
    Name: TestProduct
GPG Key:            

Sync:               
    Status:         Success
    Last Sync Date: about 1 hour
Created:            2016/06/22 03:10:53
Updated:            2016/06/22 03:11:12
Content Counts:     
    Packages:       32
    Package Groups: 2
    Errata:         4
Comment 19 Bryan Kearney 2016-07-27 11:04:14 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1501