Hide Forgot
Description of problem: system-config-date puts 'Los Angeles' in /etc/sysconfig/clock Version-Release number of selected component (if applicable): 1.9.60-2.el6.centos How reproducible: Every time you run system-config-date and select 'Los Angeles'. Steps to Reproduce: 1. Run system-config-date 2. Select Los Angeles under TimeZone 3. Press OK Actual results: Content of /etc/sysconfig/clock is: # The time zone of the system is defined by the contents of /etc/localtime. # This file is only for evaluation by system-config-date, do not rely on its # contents elsewhere. ZONE="America/Los Angeles" Expected results: Content of /etc/sysconfig/clock is: # The time zone of the system is defined by the contents of /etc/localtime. # This file is only for evaluation by system-config-date, do not rely on its # contents elsewhere. ZONE="America/Los_Angeles" Additional info: The content of the "ZONE" variable should match the file name in /usr/share/zoneinfo/ - which is /usr/share/zoneinfo/America/Los_Angeles. When this does not match - an update of the tzdata package does not update /etc/localtime.
The fix appears to be a one liner: diff --git a/src/scdate/core/timezoneBackend.py b/src/scdate/core/timezoneBackend.py index 806aaaa..605f2fa 100644 --- a/src/scdate/core/timezoneBackend.py +++ b/src/scdate/core/timezoneBackend.py @@ -56,7 +56,7 @@ class timezoneBackend(object): f.write ("# The time zone of the system is defined by the contents of /etc/localtime.\n") f.write ("# This file is only for evaluation by system-config-date, do not rely on its\n") f.write ("# contents elsewhere.\n") - f.write('ZONE="%s"\n' % timezone) + f.write('ZONE="%s"\n' % timezonefile) f.close() if self._adjtimeHasUTCInfo:
This bug is already fixed and scheduled for the next minor version of RHEL. *** This bug has been marked as a duplicate of bug 956284 ***
Thanks for confirming this will be in the next minor version of RHEL. Unfortunately I can't access bug 956284 so I have a few follow up questions. Are you able to advise when the next minor version of RHEL will be released (I assume you are referring to RHEL 6.9)? Also - I would like to review the patch used to fix this and potentially apply it manually in advance. Or is the plan to migrate to version 1.10 (which appears to take a different approach). Thanks again. And given bug 956284 is not public - this information could be useful for the next person.
(In reply to Brendan McGrath from comment #5) > Thanks for confirming this will be in the next minor version of RHEL. > > Unfortunately I can't access bug 956284 so I have a few follow up questions. > > Are you able to advise when the next minor version of RHEL will be released > (I assume you are referring to RHEL 6.9)? I'm not allowed to do that, sorry. > Also - I would like to review the patch used to fix this and potentially > apply it manually in advance. Or is the plan to migrate to version 1.10 > (which appears to take a different approach). You can apply the patch from comment#1. There's no plan to migrate to other versions.