Bug 444093

To be more accurate... timezone is set to 'Eastern' instead of 'Pacific'

Any chance you have /etc/sysconfig/clock from before system-config-date touched
things?

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.

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 :)

ZONE="America/Los_Angeles"

this was from a 20080424 install of rawhide.  20080425 is busted because of bug
444184

John -- have you continued to notice this?  (just starting an install now to try
it out for myself)

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

Still happens.  I don't see anything obviously different between the files from
before and after :-/

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

I've incorporated that patch into s-c-date upstream, version 1.9.31 with it is
building for F-10.

Confirmed fixed in current rawhide.

system-config-date-1.9.32-1.fc8 has been submitted as an update for Fedora 8

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.

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...  :-)