Bug 68149

Summary: dateconfig doesn't preserve timezone settings
Product: [Retired] Red Hat Linux Reporter: Miloslav Trmac <mitr>
Component: dateconfigAssignee: Brent Fox <bfox>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-07-07 00:25:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Miloslav Trmac 2002-07-07 00:25:08 UTC 
Version-Release number ...
dateconfig-0.7.5-7

How reproducible:
Always

Steps to Reproduce:
1.Set up system (for example using dateconfig) to timezone Europe/Prague, make
sure /etc/localtime is identical to /usr/share/zoneinfo/Europe/Prague
2.Run dateconfig, just click Save (or what is the button beside Help called in
en_US)
3.compare /etc/localtime to /usr/share/zoneinfo/Europe/Prague, execute 'date'
command

Actual Results:  /etc/localtime is changed, date shows GMT timezone.
/etc/sysconfig/clock contains
ZONE="Africa/Abidjan"
UTC=false
ARC=false

Expected Results:  /etc/localtime is not changed, date shows CEST (or CET when
DST is not in effect).
/etc/sysconfig/clock contains
ZONE="Europe/Prague"
UTC=false
ARC=false

Additional info:

When the timezone is explicitly set using dateconfig, everything is OK (I.E. it
has to be set every time you run dateconfig, or it gets changed).
Comment 1 Brent Fox 2002-07-10 01:04:30 UTC 
I believe that this has been fixed in our recent internal builds of dateconfig.
 The problem sounds related to bug #66655, which I fixed a few weeks ago.  The
new dateconfig in Rawhide should fix the problem, but dateconfig has been ported
to GTK2, so there will be a lot of new packages that you'll need.

I am unable to reproduce the behavior with the code that's currently in CVS, so
I think that this problem will not exist in future versions.  Thanks for your
report.