Bug 1403424

Summary:	system-config-date puts 'Los Angeles' in /etc/sysconfig/clock
Product:	Red Hat Enterprise Linux 6	Reporter:	Brendan McGrath <brendan>
Component:	system-config-date	Assignee:	Jan Synacek <jsynacek>
Status:	CLOSED DUPLICATE	QA Contact:	qe-baseos-daemons
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.8
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-12-12 08:38:14 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:

Description Brendan McGrath 2016-12-10 07:19:00 UTC

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.

Comment 1 Brendan McGrath 2016-12-10 07:55:15 UTC

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:

Comment 4 Jan Synacek 2016-12-12 08:38:14 UTC

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 ***

Comment 5 Brendan McGrath 2016-12-12 23:15:11 UTC

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.

Comment 6 Jan Synacek 2016-12-13 09:07:49 UTC

(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.