Bug 1384131

Summary: [SAT5] perl-DateTime-TimeZone has out-of-date tzdata information
Product: Red Hat Satellite 5 Reporter: Felipe Aranda <faranda>
Component: ServerAssignee: Tomáš Kašpárek <tkasparek>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: high Docs Contact:
Priority: high    
Version: 560CC: rfreire, tkasparek, tlestach, xdmoon
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-20 15:09:35 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:
Bug Depends On:    
Bug Blocks: 465198    

Description Felipe Aranda 2016-10-12 15:37:29 UTC 
Description of problem:

The current version of perl-DateTime-TimeZone has out-of-date daylight savings info for Chilean cities (and probably other places in the world too).  This was causing problems with scheduling actions on client systems being an hour late because the perl TimeZone module had old daylight savings dates in it which were different from the system timezone information.  This has now recified itself now that the perl TimeZone has 'caught up' with the system timezone, but for about 3 weeks they disagreed and caused scheduling problems.

Version-Release number of selected component (if applicable):
Satellite 5.x
perl-DateTime-TimeZone-0.59.1-1

How reproducible:
Always while the perl and system timezone information is different.

Steps to Reproduce:
1. Set the Satellite and client system timezone to America/Santiago
# cp /usr/share/zoneinfo/America/Santiago /etc/localtime

2. Set the date to a week ago (coz that's when the problem was occurring)
[root@rhel5sat55 ~]# date -s "2016-10-04"
Mon Oct 4 00:00:00 CLST 2016

3. In the Satellite WebUI, set the timezone to 'Brazil'

4. Schedule a remote command to be executed on the client in the next minute or so.  Note, the time for the 'Schedule no sooner than' selector on the remote_commands.pxt page will be an hour behind the current time.

5. If you set the 'Schedule no sooner than' scheduled time to a minute or two after the current time, the client won't be able to pickup the action for at least an hour.

Actual results:
Clients can't pickup actions for an hour even if the current time is selected in the 'Schedule no sooner than' selector

Expected results:
Clients should be able to pickup actions at the set time.

Additional info:
This was reproduced on Satellite 5.6 RHEL5. The Santiago.pm file hasn't been modified since 2014.
Comment 2 Tomas Lestach 2016-10-20 15:09:35 UTC 
The problem is visible only on Sat5 on RHEL5, meaning Sat5.6 on RHEL5, where perl-DateTime-TimeZone package is installed from the Satellite5.6 ISO:
# rpm -qa perl-DateTime*
perl-DateTime-0.27-10.el5
perl-DateTime-Locale-0.09-14.el5sat
perl-DateTime-TimeZone-0.59.1-1.el5sat

On RHEL6, meaning Sat5.6 and Sat5.7 on RHEL6 the problem does not happen as perl-DateTime hasn't been shipped on Satellite 5 ISO, but perl-DateTime is used directly from RHEL6. This package provides except others also perl(DateTime), perl(DateTime::Locale) and perl(DateTime::TimeZone).

# rpm -qa perl-DateTime*
perl-DateTime-0.5300-2.el6.x86_64


As the request is to address the issue on Sat5.7 I'm closing the BZ CURRENTRELEASE.