| Summary: | Wrong timestamps on failed tasks if user uses different timezone settings | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Roman Plevka <rplevka> | ||||
| Component: | Tasks Plugin | Assignee: | Adam Ruzicka <aruzicka> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Roman Plevka <rplevka> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.2.0 | CC: | aruzicka, bbuckingham, ehelms | ||||
| Target Milestone: | Unspecified | Keywords: | Triaged | ||||
| Target Release: | Unused | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| URL: | http://projects.theforeman.org/issues/15091 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | rubygem-foreman-tasks-0.7.14.6-1 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-07-27 11:14:49 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: | |||||
| Attachments: |
|
||||||
Created attachment 1144757 [details]
hammer task list
proposing blocker as this makes reviewing tasks really messy and mainly because the root cause might be more serious. Similar thing happens on using scoped search to filter records based on time. Despite the fact that I (user) use +0200 as my timezone and i can see tasks with started_at at format: "2016-04-11 13:59:02 +0200". It shows me no matches on using the date-time format without specifying the timezone: started_at = "2016-04-11 13:59:02" (0 results) started_at = "2016-04-11 11:59:02" (1 result) so it looks like the default timezone used for search (if not specified) is set to +0000 Created redmine issue http://projects.theforeman.org/issues/15091 from this bug Moving to POST since upstream bug http://projects.theforeman.org/issues/15091 has been closed VERIFIED on sat6.2.0 beta (GA14.1) # hammer task list [Foreman] Password for admin: -------------------------------------|------|-------|---------------------|---------------------|---------|---------|------------|------ ID | NAME | OWNER | STARTED AT | ENDED AT | STATE | RESULT | TASK ACTION| TASK ERRORS -------------------------------------|------|-------|---------------------|---------------------|---------|---------|------------|------ 464ad36b-f5f2-4967-a8c6-9258905b0373 | | admin | 2016/06/06 09:41:05 | 2016/06/06 09:41:05 | stopped | error | Create | Validation failed: Name has already been taken, Title has already been taken f9d4d456-8772-4876-9209-84e75caf13c7 | | admin | 2016/06/06 09:40:58 | 2016/06/06 09:41:00 | stopped | success | Create | 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/RHBA-2016:1501 |
Description of problem: There's some weird stuff going on with calculating STARTED_AT and ENDED_AT values if user uses different timezone settings than the system. While generating a successful task shows proper time, listing a task (invoked by the user) that has failed Result shows completely different time: <for better readability i'm also attaching the same output as a file. [root@sat6server ~]# date Thu Apr 7 16:21:44 CEST 2016 [root@sat6server ~]# hammer -u admin -p changeme user info --login=rplevka Id: 4 Login: rplevka Name: Email: Admin: yes Authorized by: Internal Locale: default Timezone: Eastern Time (US & Canada) Last login: 2016/04/07 13:05:29 Default organization: Default location: Roles: Anonymous User groups: Locations: Default Location Organizations: Default Organization Created at: 2016/04/07 12:53:27 Updated at: 2016/04/07 13:05:29 [root@sat6server ~]# hammer -u rplevka -p changeme organization create --name=FOO Organization created [root@sat6server ~]# hammer -u rplevka -p changeme organization create --name=FOO Could not create the organization: Name has already been taken Title has already been taken [root@sat6server ~]# hammer -u rplevka -p changeme task list -------------------------------------|------|-------------------|---------------------|---------------------|---------|---------|-------------------------------|----------------------------------------------------------------------------- ID | NAME | OWNER | STARTED AT | ENDED AT | STATE | RESULT | TASK ACTION | TASK ERRORS -------------------------------------|------|-------------------|---------------------|---------------------|---------|---------|-------------------------------|----------------------------------------------------------------------------- a36aa562-9f8d-44c4-9f48-de11ce36a4b2 | | rplevka | 2016/04/07 14:22:24 | 2016/04/07 14:22:24 | stopped | error | Create | Validation failed: Name has already been taken, Title has already been taken d8e9c744-d767-4360-a160-4e7e341b8f00 | | rplevka | 2016/04/07 10:22:14 | 2016/04/07 10:22:16 | stopped | success | Create | -------------------------------------|------|-------------------|---------------------|---------------------|---------|---------|-------------------------------|----------------------------------------------------------------------------- Version-Release number of selected component (if applicable): 6.2.0 snap6.2 How reproducible: always Steps to Reproduce: 1. create a user with different (non-default) timezone settings than system 2. being logged in as this user invoke some task - e.g. create an Organization 3. - do the same to invoke a task that fails (e.g. with using same name, etc) 4. Compare the task started_at and finished_at times Actual results: wrongly calculated timestamps (each uses different timezone probably) Expected results: If the root cause is only in displaying the timestamps, they should be always in a format (timezone) of the user listing them. Additional info: