Red Hat Bugzilla – Full Text Bug Listing
|Summary:||timezone setting made at install does not carry forward to firstboot|
|Product:||[Fedora] Fedora||Reporter:||John Poelstra <poelstra>|
|Component:||system-config-date||Assignee:||Nils Philippsen <nphilipp>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||1.9.32-1.fc8||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-07-08 22:42:38 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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 anaconda-188.8.131.52-1.i386.rpm How reproducible: 100% 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 things?
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 444184
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... :-)