Bug 444093

Summary: timezone setting made at install does not carry forward to firstboot
Product: [Fedora] Fedora Reporter: John Poelstra <poelstra>
Component: system-config-dateAssignee: Nils Philippsen <nphilipp>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: katzj, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: 1.9.32-1.fc8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-08 22:42:38 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 235706    
Description Flags
Quick fix none

Description John Poelstra 2008-04-24 18:22:40 EDT
Description of problem:
timezone settings made at install do not carry forward to firstboot

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

How reproducible:

Steps to Reproduce:
1. In anaconda select "Los Angeles" as timezone
2. Complete install
3. Reboot
4. Answer firstboot questions
5. Note that s-c-date defaults to "New York" (even if you don't go to timezone tab)
Actual results:
Timezone is set to "New York"

Expected results:
Timezone is set to "Los Angeles"

Additional info:
Comment 1 John Poelstra 2008-04-24 18:24:21 EDT
To be more accurate... timezone is set to 'Eastern' instead of 'Pacific'
Comment 2 Jeremy Katz 2008-04-24 22:20:13 EDT
Any chance you have /etc/sysconfig/clock from before system-config-date touched
Comment 3 John Poelstra 2008-04-24 22:41:21 EDT
I don't.  

You're saying it would be helpful to have this file after the installation, but
before firstboot gets to the system-config-date screen?  

I could do another install and grab it, but might not have it until tomorrow.
Comment 4 Jeremy Katz 2008-04-24 23:19:07 EDT
Yep, just switch to tty2 at the finished screen and take a look.  And if both of
us try to look tomorrow, one of us will probably succeed :)
Comment 5 John Poelstra 2008-04-25 16:03:35 EDT
Comment 6 John Poelstra 2008-04-25 16:04:42 EDT
this was from a 20080424 install of rawhide.  20080425 is busted because of bug
Comment 7 Jeremy Katz 2008-05-01 21:22:50 EDT
John -- have you continued to notice this?  (just starting an install now to try
it out for myself)
Comment 8 John Poelstra 2008-05-01 21:49:45 EDT
It was fixed a day or two ago when I selected "Vancouver, BC", however, using my
standard "Los Angeles" selection it is still broken as of today's rawhide 2008-05-01
Comment 9 Jeremy Katz 2008-05-01 22:48:31 EDT
Still happens.  I don't see anything obviously different between the files from
before and after :-/
Comment 10 Jeremy Katz 2008-05-02 17:12:33 EDT
Created attachment 304418 [details]
Quick fix

This will only happen for timezones with an _ in them because we don't get a
match (the values from teh zonetab have _ replaced with ' ').  Building
s-c-date with the attached patch
Comment 11 Nils Philippsen 2008-05-05 05:53:36 EDT
I've incorporated that patch into s-c-date upstream, version 1.9.31 with it is
building for F-10.
Comment 12 Will Woods 2008-05-05 17:28:48 EDT
Confirmed fixed in current rawhide.
Comment 13 Fedora Update System 2008-07-01 05:53:21 EDT
system-config-date-1.9.32-1.fc8 has been submitted as an update for Fedora 8
Comment 14 Fedora Update System 2008-07-08 22:42:12 EDT
system-config-date-1.9.32-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Wayne Sheridan Winch, Jr. 2008-07-18 16:24:51 EDT
Though the s-c-d now correctly translates underscores to spaces when reading the
ZONE parameter in /etc/sysconfig/clock, the inverse does not occur, i.e.,
timezone selections when committed from s-c-d, result in ZONE= values having
spaces within the city part, e.g., a selection of Los Angeles results in
ZONE=America/Los Angeles.

This does not appear to have negative consequences for mainstream Fedora apps as
the contents of /etc/localtime hold the official locality setting for the
system, which s-c-d updates as well.  However, right or wrong, with Sun's
official JRE on Fedora, Java Virtual Machines use ZONE in /etc/sysconfig/clock
to determine the current timezone setting.  Since this setting does not conform
to the expected file within the zoneinfo db (as maintained on Linux and
separately for the JRE), Java apps are only provided with the timezone ala
GMT+-D.  The net effect is that Java apps will be one hour behind the current
system time in Daylight Savings Time where the system location is set to a city
(or presumably a region) having two or more words.

This does not appear to be a problem in RHEL 5.1.  It does appear to be an issue
in Fedora 8 under the GNOME desktop environment.  I have not tested for this bug
under Fedora 9.  A simple workaround is to manually replace any spaces with
underscores in the ZONE entry of /etc/sysconfig/clock.  Regression occurs if
subsequent changes are applied in s-c-d, admittedly a rather rare occurrence.

This should probably have been entered into a new bug report...I'm quite new
around here myself and found it a bit less of an impediment to log the issue
under this related bug...  :-)