1478132 – CV erratum filter rules - start_date displayed wrong if browser timezone is behind UTC

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 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
Sub Component:
Version:	6.3.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	high
Target Milestone:	Unspecified
Assignee:	Walden Raines
QA Contact:	Roman Plevka
Docs Contact:
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)
CC List:	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
View All

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.