Bug 1478132 - CV erratum filter rules - start_date displayed wrong if browser timezone is behind UTC
Summary: CV erratum filter rules - start_date displayed wrong if browser timezone is b...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Content Views
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: Unspecified
Assignee: Walden Raines
QA Contact: Roman Plevka
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-03 16:11 UTC by Stanislav Tkachenko
Modified: 2019-04-01 20:27 UTC (History)
7 users (show)

Fixed In Version: tfm-rubygem-katello-3.4.5.56-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-21 16:54:17 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Foreman Issue Tracker 21145 0 Normal Closed CV erratum filter rules - start_date displayed wrong if browser timezone is behind UTC 2020-12-11 14:00:05 UTC

Description Stanislav Tkachenko 2017-08-03 16:11:15 UTC
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 15:46:27 UTC
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 15:51:30 UTC
Is this a regression from 6.2?

Comment 3 Stanislav Tkachenko 2017-08-04 16:21:50 UTC
(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 19:54:23 UTC
Created attachment 1331551 [details]
Update request is a day ahead

Comment 9 Dan Seethaler 2017-09-27 19:54:53 UTC
Created attachment 1331552 [details]
Response has a day ahead

Comment 10 Dan Seethaler 2017-09-27 19:55:54 UTC
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 19:57:41 UTC
(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 20:37:42 UTC
Created redmine issue http://projects.theforeman.org/issues/21145 from this bug

Comment 13 Satellite Program 2017-09-29 18:40:40 UTC
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 15:23:45 UTC
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 15:16:57 UTC
PR: https://github.com/Katello/katello/pull/7172

Comment 22 Brad Buckingham 2018-01-25 21:43:44 UTC
Moving to POST, since PR in comment 21 has been merged upstream.

Comment 25 Satellite Program 2018-02-21 16:54:17 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/RHSA-2018:0336


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