[gentoo-amd64] Problem with latest timezone update?

[gentoo-amd64] Problem with latest timezone update?

[Mark Haney]

Okay, here's something I can't seem to figure out.  My laptop time 
doesn't want to stay sync'd.  I always run ntpd at boot time to keep it 
in sync, but now, when I boot without an ethernet cable hooked up, it's 
over 5 hours off.  It didn't do this until I updated the timezone just 
after Christmas.  /etc/conf.d/clock is set to my timezone (EST5EDT) and 
/etc/localtime is symlinked to the correct timezone.

I thought maybe the BIOS clock was wrong, but it's not 5 hours off, 
maybe a minute or so.  I tried setting the HWclock to system time and 
that didn't fix it.  Any ideas on what else to try?

-- 
Recedite, plebes! Gero rem imperialem!


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Beso]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

well, do this:
add to ntpd a dependence of net.ethx so that it doesn't starts if it this
service didn't start. after that go to http://wwp.greenwichmeantime.com and
sync your time, and put to 0.000000 the first number in the /etc/adjtime
file. after that if our pc doesn't automatically sync it would be have been
sync.

2008/1/15, Mark Haney <mhaney@ercbroadband.org>:
>
> Okay, here's something I can't seem to figure out.  My laptop time
> doesn't want to stay sync'd.  I always run ntpd at boot time to keep it
> in sync, but now, when I boot without an ethernet cable hooked up, it's
> over 5 hours off.  It didn't do this until I updated the timezone just
> after Christmas.  /etc/conf.d/clock is set to my timezone (EST5EDT) and
> /etc/localtime is symlinked to the correct timezone.
>
> I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
> maybe a minute or so.  I tried setting the HWclock to system time and
> that didn't fix it.  Any ideas on what else to try?
>
> --
> Recedite, plebes! Gero rem imperialem!
>
>
> Mark Haney
> Sr. Systems Administrator
> ERC Broadband
> (828) 350-2415
>
> Call (866) ERC-7110 for after hours support
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 1750 bytes --]

Re: [gentoo-amd64] Problem with latest timezone update?

[Drake Donahue]

----- Original Message ----- 
From: "Mark Haney" <mhaney@ercbroadband.org>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Tuesday, January 15, 2008 10:22 AM
Subject: [gentoo-amd64] Problem with latest timezone update?


> Okay, here's something I can't seem to figure out.  My laptop time 
> doesn't want to stay sync'd.  I always run ntpd at boot time to keep it 
> in sync, but now, when I boot without an ethernet cable hooked up, it's 
> over 5 hours off.  It didn't do this until I updated the timezone just 
> after Christmas.  /etc/conf.d/clock is set to my timezone (EST5EDT) and 
> /etc/localtime is symlinked to the correct timezone.
> 
> I thought maybe the BIOS clock was wrong, but it's not 5 hours off, 
> maybe a minute or so.  I tried setting the HWclock to system time and 
> that didn't fix it.  Any ideas on what else to try?
> 
Could it be this simple? Quoting:

# /etc/conf.d/clock

# Set CLOCK to "UTC" if your system clock is set to UTC (also known as
# Greenwich Mean Time).  If your clock is set to the local time, then 
# set CLOCK to "local".  Note that if you dual boot with Windows, then 
# you should set it to "local".

CLOCK="local"

> -- 
> Recedite, plebes! Gero rem imperialem!
> 
> 
> Mark Haney
> Sr. Systems Administrator
> ERC Broadband
> (828) 350-2415
> 
> Call (866) ERC-7110 for after hours support
> -- 
> gentoo-amd64@lists.gentoo.org mailing list
>
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Mark Haney]

Drake Donahue wrote:
> 
> ----- Original Message ----- From: "Mark Haney" <mhaney@ercbroadband.org>
> To: <gentoo-amd64@lists.gentoo.org>
> Sent: Tuesday, January 15, 2008 10:22 AM
> Subject: [gentoo-amd64] Problem with latest timezone update?
> 
> 
>> Okay, here's something I can't seem to figure out.  My laptop time 
>> doesn't want to stay sync'd.  I always run ntpd at boot time to keep 
>> it in sync, but now, when I boot without an ethernet cable hooked up, 
>> it's over 5 hours off.  It didn't do this until I updated the timezone 
>> just after Christmas.  /etc/conf.d/clock is set to my timezone 
>> (EST5EDT) and /etc/localtime is symlinked to the correct timezone.
>>
>> I thought maybe the BIOS clock was wrong, but it's not 5 hours off, 
>> maybe a minute or so.  I tried setting the HWclock to system time and 
>> that didn't fix it.  Any ideas on what else to try?
>>
> Could it be this simple? Quoting:
> 
> # /etc/conf.d/clock
> 
> # Set CLOCK to "UTC" if your system clock is set to UTC (also known as
> # Greenwich Mean Time).  If your clock is set to the local time, then # 
> set CLOCK to "local".  Note that if you dual boot with Windows, then # 
> you should set it to "local".
> 
> CLOCK="local"
> 

Yeah it could very well be. I didn't notice that before, but for some 
reason this file was changed.  It's possible I did it and not realize 
it, but I was almost certain that I didn't update that file when I ran 
dispatch-conf.  But then again, one of my other personalities might have 
done it.  I'll have to ask around and see which one could have been the 
perp.  Thanks for picking that up.



-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Mark Knecht]

On Jan 16, 2008 5:09 AM, Mark Haney <mhaney@ercbroadband.org> wrote:
> Drake Donahue wrote:
> >
> > ----- Original Message ----- From: "Mark Haney" <mhaney@ercbroadband.org>
> > To: <gentoo-amd64@lists.gentoo.org>
> > Sent: Tuesday, January 15, 2008 10:22 AM
> > Subject: [gentoo-amd64] Problem with latest timezone update?
> >
> >
> >> Okay, here's something I can't seem to figure out.  My laptop time
> >> doesn't want to stay sync'd.  I always run ntpd at boot time to keep
> >> it in sync, but now, when I boot without an ethernet cable hooked up,
> >> it's over 5 hours off.  It didn't do this until I updated the timezone
> >> just after Christmas.  /etc/conf.d/clock is set to my timezone
> >> (EST5EDT) and /etc/localtime is symlinked to the correct timezone.
> >>
> >> I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
> >> maybe a minute or so.  I tried setting the HWclock to system time and
> >> that didn't fix it.  Any ideas on what else to try?
> >>
> > Could it be this simple? Quoting:
> >
> > # /etc/conf.d/clock
> >
> > # Set CLOCK to "UTC" if your system clock is set to UTC (also known as
> > # Greenwich Mean Time).  If your clock is set to the local time, then #
> > set CLOCK to "local".  Note that if you dual boot with Windows, then #
> > you should set it to "local".
> >
> > CLOCK="local"
> >
>
> Yeah it could very well be. I didn't notice that before, but for some
> reason this file was changed.  It's possible I did it and not realize
> it, but I was almost certain that I didn't update that file when I ran
> dispatch-conf.  But then again, one of my other personalities might have
> done it.  I'll have to ask around and see which one could have been the
> perp.  Thanks for picking that up.
>

I'm having problems after an emerge -DuN system this morning. What's
the proper solution to this?

dragonfly ~ # date
Wed Jan 16 17:45:44 Local time zone must be set--see zic manual page 2008
dragonfly ~ #

My mythbackend server is Linux only. The clock line is currently set
to UTC. timezone is Los Angeles as it's always been. It's 9:45 as I
write this but the clock thinks it's 17:45. 8 hours ahead is GMT,
right?

The hardware clock seems to be on GMT:

dragonfly ~ # hwclock -r
Wed Jan 16 17:46:35 2008  -0.584758 seconds
dragonfly ~ #

It seems the localtime file is messed up?

dragonfly ~ # cat /usr/share/zoneinfo/localtime
TZif21Local time zone must be set--see zic manual pageTZif21Local time
zone must be set--see zic manual page
<Local time zone must be set--see zic manual page>0
dragonfly ~ #

Isn't that supposed to be a link to Los_Angeles in my case? Going to
check the latest install docs.

- Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Mark Knecht]

On Jan 16, 2008 9:49 AM, Mark Knecht <markknecht@gmail.com> wrote:
>
> On Jan 16, 2008 5:09 AM, Mark Haney <mhaney@ercbroadband.org> wrote:
> > Drake Donahue wrote:
> > >
> > > ----- Original Message ----- From: "Mark Haney" <mhaney@ercbroadband.org>
> > > To: <gentoo-amd64@lists.gentoo.org>
> > > Sent: Tuesday, January 15, 2008 10:22 AM
> > > Subject: [gentoo-amd64] Problem with latest timezone update?
> > >
> > >
> > >> Okay, here's something I can't seem to figure out.  My laptop time
> > >> doesn't want to stay sync'd.  I always run ntpd at boot time to keep
> > >> it in sync, but now, when I boot without an ethernet cable hooked up,
> > >> it's over 5 hours off.  It didn't do this until I updated the timezone
> > >> just after Christmas.  /etc/conf.d/clock is set to my timezone
> > >> (EST5EDT) and /etc/localtime is symlinked to the correct timezone.
> > >>
> > >> I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
> > >> maybe a minute or so.  I tried setting the HWclock to system time and
> > >> that didn't fix it.  Any ideas on what else to try?
> > >>
> > > Could it be this simple? Quoting:
> > >
> > > # /etc/conf.d/clock
> > >
> > > # Set CLOCK to "UTC" if your system clock is set to UTC (also known as
> > > # Greenwich Mean Time).  If your clock is set to the local time, then #
> > > set CLOCK to "local".  Note that if you dual boot with Windows, then #
> > > you should set it to "local".
> > >
> > > CLOCK="local"
> > >
> >
> > Yeah it could very well be. I didn't notice that before, but for some
> > reason this file was changed.  It's possible I did it and not realize
> > it, but I was almost certain that I didn't update that file when I ran
> > dispatch-conf.  But then again, one of my other personalities might have
> > done it.  I'll have to ask around and see which one could have been the
> > perp.  Thanks for picking that up.
> >
>
> I'm having problems after an emerge -DuN system this morning. What's
> the proper solution to this?
>
> dragonfly ~ # date
> Wed Jan 16 17:45:44 Local time zone must be set--see zic manual page 2008
> dragonfly ~ #
>
> My mythbackend server is Linux only. The clock line is currently set
> to UTC. timezone is Los Angeles as it's always been. It's 9:45 as I
> write this but the clock thinks it's 17:45. 8 hours ahead is GMT,
> right?
>
> The hardware clock seems to be on GMT:
>
> dragonfly ~ # hwclock -r
> Wed Jan 16 17:46:35 2008  -0.584758 seconds
> dragonfly ~ #
>
> It seems the localtime file is messed up?
>
> dragonfly ~ # cat /usr/share/zoneinfo/localtime
> TZif21Local time zone must be set--see zic manual pageTZif21Local time
> zone must be set--see zic manual page
> <Local time zone must be set--see zic manual page>0
> dragonfly ~ #
>
> Isn't that supposed to be a link to Los_Angeles in my case? Going to
> check the latest install docs.
>
> - Mark
>
OK, the timezone update wiped out the /etc/localtime file. From the
kernel config page:

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7

it tells me to copy Los_Angeles to /etc/localtime. After I did that I
see this with date:

dragonfly ~ # date
Wed Jan 16 09:55:51 PST 2008
dragonfly ~ #

- Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Beso]

[-- Attachment #1: Type: text/plain, Size: 3672 bytes --]

that's one reason to use dispatch-conf over etc-update... at least you have
the diff on the files that are to be modified and you can chose what to do
file per file...

2008/1/16, Mark Knecht <markknecht@gmail.com>:
>
> On Jan 16, 2008 9:49 AM, Mark Knecht <markknecht@gmail.com> wrote:
> >
> > On Jan 16, 2008 5:09 AM, Mark Haney <mhaney@ercbroadband.org> wrote:
> > > Drake Donahue wrote:
> > > >
> > > > ----- Original Message ----- From: "Mark Haney" <
> mhaney@ercbroadband.org>
> > > > To: <gentoo-amd64@lists.gentoo.org>
> > > > Sent: Tuesday, January 15, 2008 10:22 AM
> > > > Subject: [gentoo-amd64] Problem with latest timezone update?
> > > >
> > > >
> > > >> Okay, here's something I can't seem to figure out.  My laptop time
> > > >> doesn't want to stay sync'd.  I always run ntpd at boot time to
> keep
> > > >> it in sync, but now, when I boot without an ethernet cable hooked
> up,
> > > >> it's over 5 hours off.  It didn't do this until I updated the
> timezone
> > > >> just after Christmas.  /etc/conf.d/clock is set to my timezone
> > > >> (EST5EDT) and /etc/localtime is symlinked to the correct timezone.
> > > >>
> > > >> I thought maybe the BIOS clock was wrong, but it's not 5 hours off,
> > > >> maybe a minute or so.  I tried setting the HWclock to system time
> and
> > > >> that didn't fix it.  Any ideas on what else to try?
> > > >>
> > > > Could it be this simple? Quoting:
> > > >
> > > > # /etc/conf.d/clock
> > > >
> > > > # Set CLOCK to "UTC" if your system clock is set to UTC (also known
> as
> > > > # Greenwich Mean Time).  If your clock is set to the local time,
> then #
> > > > set CLOCK to "local".  Note that if you dual boot with Windows, then
> #
> > > > you should set it to "local".
> > > >
> > > > CLOCK="local"
> > > >
> > >
> > > Yeah it could very well be. I didn't notice that before, but for some
> > > reason this file was changed.  It's possible I did it and not realize
> > > it, but I was almost certain that I didn't update that file when I ran
> > > dispatch-conf.  But then again, one of my other personalities might
> have
> > > done it.  I'll have to ask around and see which one could have been
> the
> > > perp.  Thanks for picking that up.
> > >
> >
> > I'm having problems after an emerge -DuN system this morning. What's
> > the proper solution to this?
> >
> > dragonfly ~ # date
> > Wed Jan 16 17:45:44 Local time zone must be set--see zic manual page
> 2008
> > dragonfly ~ #
> >
> > My mythbackend server is Linux only. The clock line is currently set
> > to UTC. timezone is Los Angeles as it's always been. It's 9:45 as I
> > write this but the clock thinks it's 17:45. 8 hours ahead is GMT,
> > right?
> >
> > The hardware clock seems to be on GMT:
> >
> > dragonfly ~ # hwclock -r
> > Wed Jan 16 17:46:35 2008  -0.584758 seconds
> > dragonfly ~ #
> >
> > It seems the localtime file is messed up?
> >
> > dragonfly ~ # cat /usr/share/zoneinfo/localtime
> > TZif21Local time zone must be set--see zic manual pageTZif21Local time
> > zone must be set--see zic manual page
> > <Local time zone must be set--see zic manual page>0
> > dragonfly ~ #
> >
> > Isn't that supposed to be a link to Los_Angeles in my case? Going to
> > check the latest install docs.
> >
> > - Mark
> >
> OK, the timezone update wiped out the /etc/localtime file. From the
> kernel config page:
>
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7
>
> it tells me to copy Los_Angeles to /etc/localtime. After I did that I
> see this with date:
>
> dragonfly ~ # date
> Wed Jan 16 09:55:51 PST 2008
> dragonfly ~ #
>
> - Mark
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 5083 bytes --]

Re: [gentoo-amd64] Problem with latest timezone update?

[Steev Klimaszewski]

On Wed, 2008-01-16 at 19:33 +0000, Beso wrote:
> that's one reason to use dispatch-conf over etc-update... at least you
> have the diff on the files that are to be modified and you can chose
> what to do file per file...
Except that neither etc-update nor dispatch-conf touch
the /etc/localtime file...

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Drake Donahue]

----- Original Message ----- 
From: "Steev Klimaszewski" <steev@gentoo.org>
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, 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 initially; it is subject to 
update by repeating the manual copy process anytime after system install.
Thus etc-update and/or dispatch-conf can't change localtime; but can change 
whether localtime runs or not.

 -- 
> gentoo-amd64@lists.gentoo.org mailing list
> 

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Mark Knecht]

On Jan 16, 2008 4:56 PM, Drake Donahue <donahue95@comcast.net> wrote:
>
> ----- Original Message -----
> From: "Steev Klimaszewski" <steev@gentoo.org>
> 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...

> 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?

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

Thanks,
Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Nicolas Litchinko]

Hi,

On Wed, Jan 16, 2008 at 05:37:21PM -0800, Mark Knecht wrote:
> On Jan 16, 2008 4:56 PM, Drake Donahue <donahue95@comcast.net> wrote:
> > 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...

There's a variable in /etc/conf.d/clock that controls whether or not
/etc/localtime should be updated when a new version of
sys-libs/timezone-data is merged: TIMEZONE. If this variable is set, the
specified timezone data file is copied over /etc/localtime.

as you can read in /etc/conf.d/clock:
# Select the proper timezone.  For valid values, peek inside of the
# /usr/share/zoneinfo/ directory.  For example, some common values are
# "America/New_York" or "EST5EDT" or "Europe/Berlin".  If you want to
# manage /etc/localtime yourself, set this to "".

If TIMEZONE is not set, /etc/localtime is not updated by
sys-libs/timezone-data. However, if TIMEZONE is set to an invalid value,
then /etc/localtime is overwritten by the "Factory" timezone data file. 

etc-update has probably changed the value of this variable after a
baselayout update. Then a timezone-data update used the wrong value to
update /etc/localtime. In your, case, the value of TIMEZONE should be
TIMEZONE="America/Los_Angeles".

-- 
Nicolas Litchinko
BOFH excuse #348:
We're on Token Ring, and it looks like the token got loose.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Peter Humphrey]

On Thursday 17 January 2008 10:15:12 Nicolas Litchinko wrote:

> There's a variable in /etc/conf.d/clock that controls whether or not
> /etc/localtime should be updated when a new version of
> sys-libs/timezone-data is merged: TIMEZONE. If this variable is set, the
> specified timezone data file is copied over /etc/localtime.
>
> as you can read in /etc/conf.d/clock:
> # Select the proper timezone.  For valid values, peek inside of the
> # /usr/share/zoneinfo/ directory.  For example, some common values are
> # "America/New_York" or "EST5EDT" or "Europe/Berlin".  If you want to
> # manage /etc/localtime yourself, set this to "".
>
> If TIMEZONE is not set, /etc/localtime is not updated by
> sys-libs/timezone-data. However, if TIMEZONE is set to an invalid value,
> then /etc/localtime is overwritten by the "Factory" timezone data file.

That's useful - thanks.

Now, how do I prevent /etc/init.d/clock being run at boot time? If I 
command "rc-update del clock" it gets put back again at shutdown time.

My reason is that I want to run chrony on my network, for its smooth 
adjustment of system time, and it can't work properly if another program 
also changes the system time.

-- 
Rgds
Peter
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Mark Knecht]

On Jan 17, 2008 2:15 AM, Nicolas Litchinko <nicolas@litchinko.fr> wrote:
> Hi,
>
> On Wed, Jan 16, 2008 at 05:37:21PM -0800, Mark Knecht wrote:
> > On Jan 16, 2008 4:56 PM, Drake Donahue <donahue95@comcast.net> wrote:
> > > 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...
>
> There's a variable in /etc/conf.d/clock that controls whether or not
> /etc/localtime should be updated when a new version of
> sys-libs/timezone-data is merged: TIMEZONE. If this variable is set, the
> specified timezone data file is copied over /etc/localtime.
>
> as you can read in /etc/conf.d/clock:
> # Select the proper timezone.  For valid values, peek inside of the
> # /usr/share/zoneinfo/ directory.  For example, some common values are
> # "America/New_York" or "EST5EDT" or "Europe/Berlin".  If you want to
> # manage /etc/localtime yourself, set this to "".
>
> If TIMEZONE is not set, /etc/localtime is not updated by
> sys-libs/timezone-data. However, if TIMEZONE is set to an invalid value,
> then /etc/localtime is overwritten by the "Factory" timezone data file.
>
> etc-update has probably changed the value of this variable after a
> baselayout update. Then a timezone-data update used the wrong value to
> update /etc/localtime. In your, case, the value of TIMEZONE should be
> TIMEZONE="America/Los_Angeles".
>
> --
> Nicolas Litchinko
> BOFH excuse #348:
> We're on Token Ring, and it looks like the token got loose.
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>

OK, I buy it. My setup was missing the underscore:

dragonfly ~ # cat /etc/conf.d/clock | grep TIMEZONE
TIMEZONE="America/LosAngeles"
dragonfly ~ #

However time on the machine has been fine for the 2 years we've had
the machine. Has this been wrong the whole time and I jsut got lucky
or did someone possibly change the formatting?

Thanks for the clarification!

Cheers,
Mark
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Drake Donahue]

----- Original Message ----- 
From: "Mark Knecht" <markknecht@gmail.com>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Thursday, January 17, 2008 10:08 AM
Subject: Re: [gentoo-amd64] Problem with latest timezone update?


> On Jan 17, 2008 2:15 AM, Nicolas Litchinko <nicolas@litchinko.fr> wrote:
>> Hi,
>>
>> On Wed, Jan 16, 2008 at 05:37:21PM -0800, Mark Knecht wrote:
>> > On Jan 16, 2008 4:56 PM, Drake Donahue <donahue95@comcast.net> wrote:
>> > > 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...
>>
>> There's a variable in /etc/conf.d/clock that controls whether or not
>> /etc/localtime should be updated when a new version of
>> sys-libs/timezone-data is merged: TIMEZONE. If this variable is set, the
>> specified timezone data file is copied over /etc/localtime.
>>
>> as you can read in /etc/conf.d/clock:
>> # Select the proper timezone.  For valid values, peek inside of the
>> # /usr/share/zoneinfo/ directory.  For example, some common values are
>> # "America/New_York" or "EST5EDT" or "Europe/Berlin".  If you want to
>> # manage /etc/localtime yourself, set this to "".
>>
>> If TIMEZONE is not set, /etc/localtime is not updated by
>> sys-libs/timezone-data. However, if TIMEZONE is set to an invalid value,
>> then /etc/localtime is overwritten by the "Factory" timezone data file.
>>
>> etc-update has probably changed the value of this variable after a
>> baselayout update. Then a timezone-data update used the wrong value to
>> update /etc/localtime. In your, case, the value of TIMEZONE should be
>> TIMEZONE="America/Los_Angeles".
>>
>> --
>> Nicolas Litchinko
>> BOFH excuse #348:
>> We're on Token Ring, and it looks like the token got loose.
>> --
>> gentoo-amd64@lists.gentoo.org mailing list
>>
>>
>
> OK, I buy it. My setup was missing the underscore:
>
> dragonfly ~ # cat /etc/conf.d/clock | grep TIMEZONE
> TIMEZONE="America/LosAngeles"
> dragonfly ~ #
>
> However time on the machine has been fine for the 2 years we've had
> the machine. Has this been wrong the whole time and I jsut got lucky
> or did someone possibly change the formatting?

Postulated sequence:
2 years ago, most probably, TIMEZONE="PST8PDT" was used.
All went well until a recent oops with etc-update or dispatch-conf, an 
inadvertent CLOCK="UTC", which caused the clock  to start keeping universal 
time.
A similar problem discussed here reported a solution which included using 
TIMEZONE="America/New_York" (I think, maybe America/Los_Angeles, maybe ...).
Having the same universal time problem, you adopted the geographic idea but 
were then bitten by a typo.
Of note, the old TIMEZONE="EST5EDT" continues to work fine here.

>
> Thanks for the clarification!
>
> Cheers,
> Mark
> -- 
> gentoo-amd64@lists.gentoo.org mailing list
> 

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Drake Donahue]

OOPS and duh!
Just reread your original!
You want to be on universal time!
Abject apologies and nevermind.

As I read /etc/init.d/clock, setting CLOCK="UTC" should make /etc/localtime 
irrelevant and unused.
If you are still having problems after the Los_Angeles change maybe 
TIMEZONE="UTC" ? 

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Problem with latest timezone update?

[Beso]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

i personally have the clock set to UTC and have kde clock set to local. this
in my opinion is the best choice and i think that every hw clock should be
set to UTC since it represents the computers' time in my opinion. every date
calculation is made converting to UTC and calculating the difference between
the UTC and the impute date converted. this is the right way to handle dates
and this, in my opinion, is the reason to why set the clock to the UTC.

2008/1/17, Drake Donahue <donahue95@comcast.net>:
>
> OOPS and duh!
> Just reread your original!
> You want to be on universal time!
> Abject apologies and nevermind.
>
> As I read /etc/init.d/clock, setting CLOCK="UTC" should make
> /etc/localtime
> irrelevant and unused.
> If you are still having problems after the Los_Angeles change maybe
> TIMEZONE="UTC" ?
>
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>


-- 
dott. ing. beso

[-- Attachment #2: Type: text/html, Size: 1251 bytes --]

Re: [gentoo-amd64] Problem with latest timezone update?

[Drake Donahue]

----- Original Message ----- 
From: "Mark Knecht" <markknecht@gmail.com>
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 <donahue95@comcast.net> wrote:
>>
>> ----- Original Message -----
>> From: "Steev Klimaszewski" <steev@gentoo.org>
>> 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