----- Original Message -----
From: "Mark Knecht" <[EMAIL PROTECTED]>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Wednesday, January 16, 2008 8:37 PM
Subject: Re: [gentoo-amd64] Problem with latest timezone update?
On Jan 16, 2008 4:56 PM, Drake Donahue <[EMAIL PROTECTED]> wrote:
----- Original Message -----
From: "Steev Klimaszewski" <[EMAIL PROTECTED]>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Wednesday, January 16, 2008 6:01 PM
Subject: Re: [gentoo-amd64] Problem with latest timezone update?
<snip>
> Except that neither etc-update nor dispatch-conf touch
> the /etc/localtime file...
>
True, but...
The files that are (maybe) affected directly by etc-update and/or
dispatch-conf are /etc/conf.d/clock and /etc/init.d/clock. ('maybe' is
used
because: an emerge update must have affected one or both files;
etc-update
and/or dispatch-conf must have been invoked by the user; the user must
have
chosen action that resulted in a change to one or both files.
/etc/conf.d/clock is the configuration file for /etc/init.d/clock.
When /etc/init.d/clock runs (normally at boot), /etc/conf.d/clock is
read.
If CLOCK="UTC" is not set in /etc/conf.d/clock,
UTC was set...
Now CLOCK="LOCAL" ?
the option --localtime is
used and TBLURB="Local Time" is set.
The /etc/localtime file is a copy of one of the binary files in
/usr/share/zoneinfo made by the system installer
installer == Mark, me the guy who built the system, correct?
yes.
initially; it is subject to
update by repeating the manual copy process anytime after system install.
Which is what I did today to fix this problem.
Thus etc-update and/or dispatch-conf can't change localtime; but can
change
whether localtime runs or not.
Humm...seems like what you say is true but doesn't explain how emerge
-DuN system changed the file. It was clearly changed since I could
look inside with vi and compare to the Los_Angeles file and see that
they were clearly different...
Probably the previous /etc/localtime file was a copy of PST8PDT.
IIRC the geographic file names are relatively recent in origin.
If the old localtime had PST8PDT and the new had Los_Angeles in the few
readable characters the difference is explained.
Alternatively:
The start and end of US daylight savings time changed effective 2007-2008.
This resulted in an update to PST8PDT and its cousins ( to Los_Angeles and
its geographic cousins also, if they existed before the change). The
timezone-data ebuild also has a series of more recent bugfixes.
As Nicholas explains the /sys-libs/timezone-data update ebuild should have
updated /usr/share/zoneinfo files to new versions.
The /sys-libs/timezone-data update ebuild should then have copied the new
version of the file named in /etc/conf/clock's TIMEZONE= statement from
/usr/share/zoneinfo to /etc/localtime.
If it did not succeed in updating /etc/localtime because TIMEZONE= was
blank, invalid, or not set, the old /etc/localtime would have contained
readable characters: ' Local time zone must be set -- see zic manual page'.
Thanks,
Mark
--
gentoo-amd64@lists.gentoo.org mailing list
--
gentoo-amd64@lists.gentoo.org mailing list
