# Date and time problem

## ashtrash

Hi,

my date and time is changing every time i reboot under linux (everything works fine under windows). Everything worked fine but some time ago (I don't know what have I done) date is changing just like that, one day it is for example 13/04/2006 about 22.00 next time i load system it is few hours earlier, next time it is few days earlier... and finally it gets even to 2005. I have no idea why does it happen. Anyone has any idea?

----------

## yabbadabbadont

What are the contents of your /etc/conf.d/clock file?

----------

## ashtrash

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

#CLOCK="local"

CLOCK="UTC"

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

# you may do so here.

CLOCK_OPTS=""

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

# during shutdown, then say "yes" here.

CLOCK_SYSTOHC="no"

### ALPHA SPECIFIC OPTIONS ###

# If your alpha uses the SRM console, set this to "yes".

SRM="no"

# If your alpha uses the ARC console, set this to "yes".

ARC="no"

```

I suppose the most important thing for me was to find this file:). i'll try local here.

...

It didn't help   :Sad: 

----------

## gojyo

I have the same problem:

when I boot in Gentoo, the clock is set at some hour of the previous day...

Usually (but I'm not very sure about this), is set a few hours before the last time I shut down the pc.

I use kde, but the date is wrong even without starting it (so, it's not a kde problem).

When I start the pc, the BIOS shows the right date, and so does Windoz.

I'm almost sure that the problem has arised after a world update, but I really don't remember what I've updated exactly.

My /etc/conf.d/clock is the same as the above, except for CLOCK="UTC" which is, instead, CLOCK="local".

----------

## EugeneTSWong

I had a similar problem. If I recall correctly, the clock went ahead after each reboot by about 20 minutes. It could have been back, as opposed to ahead.

I "solved" the problem by editing the boot & shutdown scripts, and commenting out any code that tried to update any clocks. I still don't know the problem. I just know that it was Gentoo.

I hope that helps.

----------

## ePharaoh

I think my troubles started when I had a long power outage at my home last week.

Some of my startup scripts got munged, and my eth0 interface refused to load.

I had to reinstall "sys-apps/baselayout", but that didn't work. When I updated it to the latest test version, the eth0 interface worked fine.

But, the clock is giving me trouble. The current version that I have is,

sys-apps/baselayout-1.12.0_pre18-r1

Other related package versions,

sys-apps/sysvinit-2.86-r5

sys-kernel/gentoo-sources-2.6.16-r1

----------

## ashtrash

In my situation the /etc/init.d/clock script is a main problem. when i mv clock clockbak it shows some errors/warnings at startup but the clock works fine. I think i'll just comment proper instructions in this script and leave it alone since absence of this script doesn't cause any further problems for me (excluding startup errors).

----------

## gojyo

I've seen that the clock init script runs this command at startup:

```
/sbin/hwclock --hctosys
```

However, this works properly from a console, so the problem it's not in the hwclock program.

I'll make some other tests and tell you if I found something.

----------

## ePharaoh

I think it would be helpful, if everybody posts the version number of related software.

That way, we can pin down the culprit. Obviously, it is some recent upgrade that is causing the problem!

tip: to find out which package a file belongs to, you can use the tool 'equery'.

for example,

```
equery b /etc/init.d/clock
```

Also, perhaps this has got something to do with SMP systems. I have a P4 with HT.

I have tried both "enhanced RTC support" and the "normal RTC" support in kernel.

----------

## gojyo

 *ePharaoh wrote:*   

> Also, perhaps this has got something to do with SMP systems. I have a P4 with HT.
> 
> I have tried both "enhanced RTC support" and the "normal RTC" support in kernel.

 

I have a Athlon64, and the problem for me has arised without a kernel change (2.6.14-gentoo), so I think kernel and cpu are innocent  :Smile: 

----------

## eliocg

Had anyone got the solution to this??

I just installed Gentoo in this AMD64 machine and the clock get changed at every boot.

----------

## runningwithscissors

This is all I do and the clock works fine, even when dual booting with windows.

Check that your BIOS clock is set to the local time.

Symlink the timezone file to /etc/localtime

Change the CLOCK option in /etc/conf.d/clock to local.

Works every time.

----------

## eliocg

 *runningwithscissors wrote:*   

> Check that your BIOS clock is set to the local time.
> 
> Symlink the timezone file to /etc/localtime
> 
> Change the CLOCK option in /etc/conf.d/clock to local.
> ...

 

Well, it didn't work for me... What i did was:

1. delete /etc/adjtime

2. remove ${adjtime} from the parameters passed to hwclock in /etc/init.d/clock

3. reboot

Solutii

Now my clock is working correctly. I guess this is a bug, should i report it?

----------

## gtbX

eliocg's solution worked for me.  Just removed /etc/adjtime and set the correct time in the bios.

----------

## gojyo

It worked for me too.

Anyway, what the adjtime file was intended for?

----------

## Keruskerfuerst

Deleting the file /etc/adjtime corrected the problem, but after the next reboot, the file exists and sets the clock 2 hours in the past.

----------

## Keruskerfuerst

Now I am using the ntp-client to set the correct time and date.

----------

## saty

Hi,

same problem here... after booting, the clock is two hours back.

 *Quote:*   

> Check that your BIOS clock is set to the local time.
> 
> Symlink the timezone file to /etc/localtime
> 
> Change the CLOCK option in /etc/conf.d/clock to local. 

 

I tried this and found a dead link in /etc/localtime

/usr/share/zoneinfo/Europe/Berlin doesn't exist anymore. There is just:

```

drwxr-xr-x 3 root root 128 Apr 20 20:45 America

drwxr-xr-x 2 root root  72 Apr 20 20:44 Australia

drwxr-xr-x 2 root root  80 Apr 20 20:44 US

-rw-r--r-- 1 root root 101 Feb 11 09:24 localtime

drwxr-xr-x 5 root root 128 Apr 20 20:45 posix

drwxr-xr-x 5 root root 128 Apr 20 20:45 right

```

How can i get back Europe in there?

 :Smile: 

----------

## saty

Found it:

```
emerge sys-libs/timezone-data
```

 :Smile: 

----------

## $moke

I had the same problems with clock. My clock was set to almost random hour, minutes and even dates on every reboot. I tried some other distros and they were fine, so I toke the kernel from one of them (RR4) and switched with gentoo`s one, the problem wasn`t solved. So the problem seems to be in the initscripts or in configuration. A few minutes ago I recheked whether /etc/localtime was properly linked to my location and it wasn`t (a friend of mine has changed it with KDE`s utility). I relinked it and for now (3 reboots) everything seems to be OK  :Smile: .

----------

## wynn

From  the manpage hwclock (note digit 8-close paren is cool   :Smile:  )

 *Quote:*   

> The Adjust Function
> 
>        The  Hardware Clock is usually not very accurate.  However, much of its
> 
>        inaccuracy is completely predictable -  it  gains  or  loses  the  same
> ...

  If, as happened to me, the clock, for some reason, is out by several hours and you adjust it "(using --set or --systohc )" then it puts a huge drift value into /etc/adjtime and, every time the init script does  *Quote:*   

> a hwclock --adjust just before the  hwclock  --hctosys at system startup time

  the time is moved wildly in one direction or the other.

If you delete /etc/adjtime then a new one with the default settings

```
0.000000 0 0

0

UTC
```

 is made. The format of the file is

 *Quote:*   

>        The format of the adjtime file is, in ASCII:
> 
>        Line 1: 3 numbers, separated by blanks: 1)  systematic  drift  rate  in
> 
>        seconds per day, floating point decimal; 2) Resulting number of seconds
> ...

  The third value on line 1 is often found to be 0.000000

----------

