Bug 1478132 - CV erratum filter rules - start_date displayed wrong if browser timezone is behind UTC
CV erratum filter rules - start_date displayed wrong if browser timezone is b...
Status: CLOSED ERRATA
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Content Views (Show other bugs)
6.3.0
Unspecified Unspecified
unspecified Severity high (vote)
: GA
: --
Assigned To: Walden Raines
Roman Plevka
: Regression, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-03 12:11 EDT by Stanislav Tkachenko
Modified: 2018-02-21 11:54 EST (History)
7 users (show)

See Also:
Fixed In Version: tfm-rubygem-katello-3.4.5.56-1
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-02-21 11:54:17 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot (48.05 KB, image/png)
2017-08-03 12:11 EDT, Stanislav Tkachenko
no flags Details
Update request is a day ahead (250.46 KB, image/png)
2017-09-27 15:54 EDT, Dan Seethaler
no flags Details
Response has a day ahead (246.79 KB, image/png)
2017-09-27 15:54 EDT, Dan Seethaler
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 21145 None None None 2017-09-27 16:37 EDT

  None (edit)
Description Stanislav Tkachenko 2017-08-03 12:11:15 EDT
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:
Comment 1 Stanislav Tkachenko 2017-08-04 11:46:27 EDT
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'.
Comment 2 Brad Buckingham 2017-08-04 11:51:30 EDT
Is this a regression from 6.2?
Comment 3 Stanislav Tkachenko 2017-08-04 12:21:50 EDT
(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'
Comment 8 Dan Seethaler 2017-09-27 15:54 EDT
Created attachment 1331551 [details]
Update request is a day ahead
Comment 9 Dan Seethaler 2017-09-27 15:54 EDT
Created attachment 1331552 [details]
Response has a day ahead
Comment 10 Dan Seethaler 2017-09-27 15:55:54 EDT
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
Comment 11 Dan Seethaler 2017-09-27 15:57:41 EDT
(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.
Comment 12 Dan Seethaler 2017-09-27 16:37:42 EDT
Created redmine issue http://projects.theforeman.org/issues/21145 from this bug
Comment 13 pm-sat@redhat.com 2017-09-29 14:40:40 EDT
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/21145 has been resolved.
Comment 20 Roman Plevka 2018-01-24 10:23:45 EST
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)
Comment 21 Walden Raines 2018-01-25 10:16:57 EST
PR: https://github.com/Katello/katello/pull/7172
Comment 22 Brad Buckingham 2018-01-25 16:43:44 EST
Moving to POST, since PR in comment 21 has been merged upstream.
Comment 25 pm-sat@redhat.com 2018-02-21 11:54:17 EST
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

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