# Hardware clock is right, but "date" won't catch up[SOLVED]

## Punchcutter

I have had clock troubles before (not necessarily under Gentoo), and they always seem to resolve themselves after some time.  Now I'm having a frustrating problem with Gentoo:  my hardware clock (hwclock) reports the correct (local) time.  And my /etc/conf.d/clock is set up correctly (AFAICT), as follows:

```
CLOCK="local"

TIMEZONE="America/Denver"

```

Also, /etc/localtime is correct.

But "date" (and other GUI clocks) reports UTC time (currently local + 6).  Even if I use the setting function of "date" to reset it,

each time I reboot, I'm back to this broken state again.

Can anyone suggest what I'm missing here?

Thanks,

DaveLast edited by Punchcutter on Sun Jun 01, 2008 7:27 pm; edited 1 time in total

----------

## SeaTiger

In UNIX/Linux world, the hardware/cmos clock usually is set to UTC time. If you have hwclock set to localtime, and then use TZ, it is very easy to mess up time in file system. Following is my setting:

/etc/conf.d/hwclock

```
# 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="UTC"

# If you want to set the Hardware Clock to the current System Time 

# during shutdown, then say "YES" here.

# You normally don't need to do this if you run a ntp daemon.

clock_systohc="YES"

# If you wish to pass any other arguments to hwclock during bootup,

# you may do so here. Alpha users may wish to use --arc or --srm here.

clock_args=""
```

/etc/localtime should be a copy of or soft link to (in your case) /usr/share/zoneinfo/America/Denver.

/etc/timezone

```
America/Denver
```

Since Gentoo move to baselayout2/openRC, /etc/conf.d/clock is obsolete and replaced by /etc/conf.d/hwclock.

----------

## Punchcutter

 *junksiu wrote:*   

> Since Gentoo move to baselayout2/openRC, /etc/conf.d/clock is obsolete and replaced by /etc/conf.d/hwclock.

 This is the critical piece of info I was missing.  I was marginally aware of this switch to OpenRC, but it seems to me it was not publicized nearly well enough.... the implications are potentially devastating, and yet this happened to my system without my being especially aware of it.  If any developers are reading this: make sure your userbase knows what's happening and give them a chance to react to it!

Needless to say, when I switched over to using the hwclock file (and read the doc page on OpenRC transition), the clock got set to the correct time.

Thanks,

Dave

----------

## yabbadabbadont

You must be running a fully unstable system if you got the new baselayout and openrc.  They haven't been marked stable yet.  Before they are, I'm sure that they will receive a lot more publicity.

----------

## Punchcutter

D'oh!   :Embarassed:   I've been running Gentoo for over a year now (on another machine) and I was not familiar with how the concept of "stable/unstable" is used in portage!  Now that I check the docs, I see it is controlled by the ACCEPT_KEYWORDS="~x86", which I decided on a whim to include in this install, not fully understanding the ramifications.  Live and learn  :Rolling Eyes: 

If I want to go back to a stable system, but keep the new baselayout and OpenRC (I've already changed a lot of stuff in my /etc as a result), is that gonna cause a big mess? Should I just avoid changing the ACCEPT_KEYWORDS at this point?

(update: I just did emerge -pvuDN world after commenting out ACCEPT_KEYWORDS in make.conf, and there are about 20 packages that are now masked, i.e. that don't belong in a stable system, including my kernel   :Sad:   Looks like a mess.... but I'm hoping there's a magic way to work around this, that one of you guys can tell me  :Smile: )

Thanks!

Dave

p.s. I'm starting to wonder if this might be related to another problem I'm currently having?

----------

## Punchcutter

I've decided to jump in with both feet and consider it a learning experience... this is not a machine anyone is depending on at this point, so I can take time to use it this way....

I've removed ~x86 from make.conf, added a few things like gentoo-sources, baselayout and openrc to package.keywords with ~x86 to keep them at the newer versions, and started an emerge -uDN world (I did a --sync earlier in the evening so I should be ok there)

Wish me luck....   :Shocked:   Any hints about important things I may have overlooked are deeply appreciated...

Dave

----------

## yabbadabbadont

Be sure to run revdep-rebuild after your emerge finishes.  It is part of gentoolkit if you don't already have it.  Run it with "--pretend" first, just as you would with emerge, to see what it is going to do.

If you still run into weird issues, even after that, then it would probably be time to run: emerge -e system && emerge -e world

so that the entire toolchain and all libraries are consistent.

----------

## Punchcutter

Thanks again for the advice... although I was able to re-emerge world successfully and revdep-rebuild fixed a couple things and seemed to work fine as well, I am in fact now getting a weirdness with X, as documented in this new thread.  I'm hoping someone can help me fix this without re-emerging the world again with -e, but if it comes to that, then I guess that's what I learned as a result of this experiment  :Smile: 

Dave

----------

