Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 72149 - Time zone's value ignores the current setting
Summary: Time zone's value ignores the current setting
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-date
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Mike McLean
URL:
Whiteboard:
: 78935 79772 84028 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-08-21 14:48 UTC by Akira TAGOH
Modified: 2007-04-18 16:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-10-22 18:56:46 UTC


Attachments (Terms of Use)

Description Akira TAGOH 2002-08-21 14:48:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020809

Description of problem:
a value of the list view on the Time zone tab ignores the current setting. looks
like it's always pointed America/New_York.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.runs redhat-config-date
2.select the Time zone tab.
3.look at the list view.
	

Actual Results:  I've selected 'Asia/Tokyo' for Time zone at the install time,
but redhat-config-date always point 'America/New_York.

Expected Results:  the current setting's value should be selected by default.

Additional info:

Comment 1 Brent Fox 2002-08-21 20:26:37 UTC
Should be fixed in 1.5.2-3.

QA, please verify.

Comment 2 Mike McLean 2002-09-12 06:45:14 UTC
Hmm, there seems to be qa contact for this bug, adding myself.

This bug is fixed in the literal sense: redhat-config-date does indeed read the
currect timezone/utc settings from /etc/sysconfig/clock.  However, any changes
mad e are not written back to this file.  I am testing with 
redhat-config-date-1.5.2-10.

See also bug#73498.

Comment 3 Brent Fox 2002-10-10 19:21:05 UTC
The fix is in CVS now, but I can't push new packages to Rawhide now due to some
problem with the build system.  Should be fixed in 1.5.2-11.  

QA, please verify.  The RPM can be found in dist-8.0.1.

Comment 4 Mike McLean 2002-10-10 19:53:56 UTC
um...........  

[mike@test114 mike]$ /usr/bin/redhat-config-date
Traceback (most recent call last):
  File "/usr/share/redhat-config-date/redhat-config-date.py", line 35, in ?
    mainWindow.mainWindow().stand_alone()
  File "/usr/share/redhat-config-date/mainWindow.py", line 180, in __init__
    self.timezonePage = timezone_gui.timezonePage()
  File "/usr/share/redhat-config-date/timezone_gui.py", line 53, in __init__
    if int(self.asUTC) == 1:
ValueError: invalid literal for int(): true
[mike@test114 mike]$ rpm -q redhat-config-date
redhat-config-date-1.5.2-11
[root@test114 root]# cat /etc/sysconfig/clock
ZONE="America/New_York"
UTC=true
ARC=false

it seems to be thrown off by boolean keywords like true/false on/off.  It seems
to want to only see 0/1 and it seems to always write 0/1.  Note that rc.sysinit
*doesn't understand* 0 or 1 for UTC or ARC, though to be fair this is probably a
bug in initscripts (since it does initialize them to be 0).

Comment 5 Bill Nottingham 2002-10-10 20:05:32 UTC
UTC/ARC is a true/false field, not a 0/1 field. At least, that's how it's
documented and implemented. ;)

Comment 6 Brent Fox 2002-10-22 18:56:38 UTC
Should be fixed properly now (hopefully).  Please test with
redhat-config-date-1.5.3-1 in dist-8.0.1

Comment 7 Mike McLean 2002-10-23 12:21:52 UTC
Confirmed fix.
CLOSING->RAWHIDE

Comment 8 Brent Fox 2002-12-03 19:40:40 UTC
*** Bug 78935 has been marked as a duplicate of this bug. ***

Comment 9 Brent Fox 2002-12-17 17:37:57 UTC
*** Bug 79772 has been marked as a duplicate of this bug. ***

Comment 10 Brent Fox 2003-02-11 17:06:02 UTC
*** Bug 84028 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.