Bug 2060613

Summary: Dates specified in search queries don't respect current user time zone
Product: Red Hat Satellite Reporter: Joniel Pasqualetto <jpasqual>
Component: SearchAssignee: Adam Ruzicka <aruzicka>
Status: CLOSED ERRATA QA Contact: Peter Ondrejka <pondrejk>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.9.8CC: afeferku, ajambhul, apatel, aruzicka, kgaikwad, lstejska, mhulan, ofedoren, pcreech, rabajaj, rlavi, yyadav
Target Milestone: 6.14.0Keywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rubygem-scoped_search-4.1.11 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-11-08 14:17:47 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:

Description Joniel Pasqualetto 2022-03-03 21:05:17 UTC
Description of problem:

Not sure if this is a regression or if this specific component was not considered on https://bugzilla.redhat.com/show_bug.cgi?id=1709902

When querying for job-invocations and filtering by date, the query is done using UTC times and not the local time zone of the user.

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

Observed on Satellite 6.9.8

How reproducible:


Steps to Reproduce:

1. Having a job invocation associated with a task having the following properties: 

~~~
#  select id,started_at,start_at,action from foreman_tasks_tasks where id = 'c790768a-60a6-4c1a-bccf-74419654a376';
-[ RECORD 1 ]--------------------------------------------
id         | c790768a-60a6-4c1a-bccf-74419654a376
started_at | 2022-03-03 00:30:37.21
start_at   | 2022-03-03 00:30:37.21
action     | Run hosts job: Install errata RHSA-2021:3572
~~~

Being on timezone EST (-0500) and running this query, returns nothing.

~~~
#  hammer -u admin -p password job-invocation list --search 'YESTERDAY' --order "id asc"
---|-------------|--------|---------|--------|---------|-------|-------|---------------------|-------
ID | DESCRIPTION | STATUS | SUCCESS | FAILED | PENDING | TOTAL | START | RANDOMIZED ORDERING | INPUTS
---|-------------|--------|---------|--------|---------|-------|-------|---------------------|-------
~~~

Note that the "2022-03-03 00:30:37.21 UTC" is "2022-03-02 19:30:37.21 -0500" and should be returned to the query, as it is "yesterday" for the local user.

Looking at the sql logs on foreman, this is the kind of filter I see, simply filtering by the day and not taking in consideration timezones.

~~~
("foreman_tasks_tasks"."started_at" >= '2022-03-02' AND "foreman_tasks_tasks"."started_at" < '2022-03-03') OR ("foreman_tasks_tasks"."start_at" >= '2022-03-02' AND "foreman_tasks_tasks"."start_at" < '2022-03-03') OR ("foreman_tasks_tasks"."ended_at" >= '2022-03-02' AND "foreman_tasks_tasks"."ended_at" < '2022-03-03')
~~~

2. Having this task data:

~~~
# select id,started_at,start_at,action from foreman_tasks_tasks where id = 'c790768a-60a6-4c1a-bccf-74419654a376';
-[ RECORD 1 ]--------------------------------------------
id         | c790768a-60a6-4c1a-bccf-74419654a376
started_at | 2022-03-02 00:30:37.21
start_at   | 2022-03-02 00:30:37.21
action     | Run hosts job: Install errata RHSA-2021:3572
~~~

Being on timezone EST (-0500) and running this query, returns jobs from 2 days ago(2022-03-01)

~~~
#  hammer -u admin -p password job-invocation list --search 'YESTERDAY' --order "id asc"
------|-------------------------------|--------|---------|--------|---------|-------|--------------------------
ID    | DESCRIPTION                   | STATUS | SUCCESS | FAILED | PENDING | TOTAL | START                    
------|-------------------------------|--------|---------|--------|---------|-------|--------------------------
30701 | Install errata RHSA-2021:3572 | failed | 0       | 4      | 0       | 4     | 2022-03-01 19:30:37 -0500
------|-------------------------------|--------|---------|--------|---------|-------|--------------------------
~~~

Actual results:

Returns wrong results.

Expected results:

Should take in consideration local time for queries.

Additional info:

Comment 2 Adam Ruzicka 2022-03-07 14:36:48 UTC
This comes from the library we're using for searching. If you use just "yesterday", it indeed omits the time part completely, including the time zone. As a workaround, searching for "24 hours ago" should work

Comment 10 Adam Ruzicka 2023-05-29 12:49:11 UTC
The fix was merged in upstream

Comment 13 Peter Ondrejka 2023-07-14 07:37:46 UTC
Verified on Sat 6.14 sn 7 using the query from the problem description

Comment 16 errata-xmlrpc 2023-11-08 14:17:47 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 (Important: Satellite 6.14 security and bug fix update), 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-2023:6818