Red Hat Bugzilla – Bug 1478132
CV erratum filter rules - start_date displayed wrong if browser timezone is behind UTC
Last modified: 2018-02-21 11:54:17 EST
Created attachment 1308789 [details] Screenshot Description of problem: Timezone was set to America/Toronto, local date and time was 2017-08-03 11:12:03, start date was set to 2017-08-03. CV, CV filter and CV filter rule were created via API. However, UI shows start_day for previous day, 2017-08-02. API shows correct date. 2017-08-03 11:12:03 7ddffec5 [app] [I] Started POST "/katello/api/v2/content_view_filters/18/rules" for 10.36.117.101 at 2017-08-03 11:1 2:03 -0400 2017-08-03 11:12:03 7ddffec5 [app] [I] Processing by Katello::Api::V2::ContentViewFilterRulesController#create as */* 2017-08-03 11:12:03 7ddffec5 [app] [I] Parameters: {"end_date"=>"2017-08-08", "content_view_filter_id"=>"18", "date_type"=>"issued", " start_date"=>"2017-08-03", "api_version"=>"v2", "content_view_filter_rule"=>{"end_date"=>"2017-08-08", "content_view_filter_id"=>"18", "date_type"=>"issued", "start_date"=>"2017-08-03"}} Version-Release number of selected component (if applicable): Satellite 6.3.0 Snap 9.0: * satellite-6.3.0-16.0.beta.el7sat.noarch * katello-3.4.2-1.el7sat.noarch * foreman-1.15.2-1.el7sat.noarch How reproducible: Always Steps to Reproduce: 1. Set timezone behind UTC, e.g. -4 2. Create CV, Erratum CV filter and filter rule via API and set start_date to current date. 3. Navigate to Content -> Content Views -> Yum Content -> Filters and check start date Actual results: Date is set to 1 day before current date. Expected results: Additional info:
I've set timzeone globally to the system using timedatectl, like: > timedatectl set-timezone America/Toronto And in UI/user settings timezone was set to 'Browser timezone'.
Is this a regression from 6.2?
(In reply to Brad Buckingham from comment #2) > Is this a regression from 6.2? Yes, on 6.2.11 correct date is displayed, but in different format though: '04-August-2017'
Created attachment 1331551 [details] Update request is a day ahead
Created attachment 1331552 [details] Response has a day ahead
I've validated the issue upstream. I can see from the network requests that the date being sent to the server is actually a day ahead
(In reply to Dan Seethaler from comment #9) > Created attachment 1331552 [details] > Response has a day ahead When reloading the page the api is returning the same date (one day ahead). I don't see this issue upstream and I haven't been able to identify what fixes this as of yet.
Created redmine issue http://projects.theforeman.org/issues/21145 from this bug
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/21145 has been resolved.
I reproduce this pretty easily. I have my browser in CET zone (GMT +1; UTC+1). my (and also our automation) admin user has the "browser default timezone" set as a timezone. - whenever i pick a date using ui (e.g. 2018-01-24), the UI issues a (POST/PUT) request to api, transforming the date to UTC. Despite the fact, that we're only interested in a day, the whole time information is being sent out, (in my specific case: 2018-01-24 00:00:00.000Z => which, converted to UTC is 1hr less => 2018-01-23 23:00:00.000Z): 2018-01-24 07:16:29 87b14474 [app] [I] Started PUT "/katello/api/v2/content_view_filters/2/rules/1" ... 2018-01-24 07:16:29 87b14474 [app] [I] Processing by Katello::Api::V2::ContentViewFilterRulesController#update as JSON 2018-01-24 07:16:29 87b14474 [app] [I] Parameters: { "content_view_filter_id"=>"2", "types"=>["security", "enhancement", "bugfix"], "date_type"=>"updated", "id"=>"1", "created_at"=>"2018-01-24 13:16:10 +0100", "updated_at"=>"2018-01-24 13:16:10 +0100", "start_date"=>"2018-01-23T23:00:00.000Z", "end_date"=>"2018-01-23T23:00:00.000Z", "api_version"=>"v2", ... } The ui doesn't seem to convert it back to the appropriate TZ after loading it back to the datepicker (it probably just extracts the date)
PR: https://github.com/Katello/katello/pull/7172
Moving to POST, since PR in comment 21 has been merged upstream.
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/RHSA-2018:0336