| 1 |
----- Original Message ----- |
| 2 |
From: "Mark Knecht" <markknecht@×××××.com> |
| 3 |
To: <gentoo-amd64@l.g.o> |
| 4 |
Sent: Thursday, January 17, 2008 10:08 AM |
| 5 |
Subject: Re: [gentoo-amd64] Problem with latest timezone update? |
| 6 |
|
| 7 |
|
| 8 |
> On Jan 17, 2008 2:15 AM, Nicolas Litchinko <nicolas@×××××××××.fr> wrote: |
| 9 |
>> Hi, |
| 10 |
>> |
| 11 |
>> On Wed, Jan 16, 2008 at 05:37:21PM -0800, Mark Knecht wrote: |
| 12 |
>> > On Jan 16, 2008 4:56 PM, Drake Donahue <donahue95@×××××××.net> wrote: |
| 13 |
>> > > Thus etc-update and/or dispatch-conf can't change localtime; but can |
| 14 |
>> > > change |
| 15 |
>> > > whether localtime runs or not. |
| 16 |
>> > |
| 17 |
>> > Humm...seems like what you say is true but doesn't explain how emerge |
| 18 |
>> > -DuN system changed the file. It was clearly changed since I could |
| 19 |
>> > look inside with vi and compare to the Los_Angeles file and see that |
| 20 |
>> > they were clearly different... |
| 21 |
>> |
| 22 |
>> There's a variable in /etc/conf.d/clock that controls whether or not |
| 23 |
>> /etc/localtime should be updated when a new version of |
| 24 |
>> sys-libs/timezone-data is merged: TIMEZONE. If this variable is set, the |
| 25 |
>> specified timezone data file is copied over /etc/localtime. |
| 26 |
>> |
| 27 |
>> as you can read in /etc/conf.d/clock: |
| 28 |
>> # Select the proper timezone. For valid values, peek inside of the |
| 29 |
>> # /usr/share/zoneinfo/ directory. For example, some common values are |
| 30 |
>> # "America/New_York" or "EST5EDT" or "Europe/Berlin". If you want to |
| 31 |
>> # manage /etc/localtime yourself, set this to "". |
| 32 |
>> |
| 33 |
>> If TIMEZONE is not set, /etc/localtime is not updated by |
| 34 |
>> sys-libs/timezone-data. However, if TIMEZONE is set to an invalid value, |
| 35 |
>> then /etc/localtime is overwritten by the "Factory" timezone data file. |
| 36 |
>> |
| 37 |
>> etc-update has probably changed the value of this variable after a |
| 38 |
>> baselayout update. Then a timezone-data update used the wrong value to |
| 39 |
>> update /etc/localtime. In your, case, the value of TIMEZONE should be |
| 40 |
>> TIMEZONE="America/Los_Angeles". |
| 41 |
>> |
| 42 |
>> -- |
| 43 |
>> Nicolas Litchinko |
| 44 |
>> BOFH excuse #348: |
| 45 |
>> We're on Token Ring, and it looks like the token got loose. |
| 46 |
>> -- |
| 47 |
>> gentoo-amd64@l.g.o mailing list |
| 48 |
>> |
| 49 |
>> |
| 50 |
> |
| 51 |
> OK, I buy it. My setup was missing the underscore: |
| 52 |
> |
| 53 |
> dragonfly ~ # cat /etc/conf.d/clock | grep TIMEZONE |
| 54 |
> TIMEZONE="America/LosAngeles" |
| 55 |
> dragonfly ~ # |
| 56 |
> |
| 57 |
> However time on the machine has been fine for the 2 years we've had |
| 58 |
> the machine. Has this been wrong the whole time and I jsut got lucky |
| 59 |
> or did someone possibly change the formatting? |
| 60 |
|
| 61 |
Postulated sequence: |
| 62 |
2 years ago, most probably, TIMEZONE="PST8PDT" was used. |
| 63 |
All went well until a recent oops with etc-update or dispatch-conf, an |
| 64 |
inadvertent CLOCK="UTC", which caused the clock to start keeping universal |
| 65 |
time. |
| 66 |
A similar problem discussed here reported a solution which included using |
| 67 |
TIMEZONE="America/New_York" (I think, maybe America/Los_Angeles, maybe ...). |
| 68 |
Having the same universal time problem, you adopted the geographic idea but |
| 69 |
were then bitten by a typo. |
| 70 |
Of note, the old TIMEZONE="EST5EDT" continues to work fine here. |
| 71 |
|
| 72 |
> |
| 73 |
> Thanks for the clarification! |
| 74 |
> |
| 75 |
> Cheers, |
| 76 |
> Mark |
| 77 |
> -- |
| 78 |
> gentoo-amd64@l.g.o mailing list |
| 79 |
> |
| 80 |
|
| 81 |
-- |
| 82 |
gentoo-amd64@l.g.o mailing list |
Archives