# hwclock and localtime problem

## xoJIog

The problem is that system will modify system time based on /etc/localtime, even if hwlock is set to local time:

Setting hwclock to local true time:

```
cat /etc/conf.d/hwclock

clock="local"

clock_hctosys="YES"

clock_systohc="YES"

clock_args=""

```

```
cp /usr/share/zoneinfo/Europe/Riga /etc/localtime

date

Fri Jul 31 15:38:26 EEST 2015

hwclock -w --localtime

hwclock -r --localtime

Fri Jul 31 15:38:30 2015  -0.911500 seconds

```

System reboot:

```
reboot

date

Fri Jul 31 18:41:42 EEST 2015

hwclock --localtime

Fri Jul 31 15:41:57 2015  -0.193070 seconds

rm /etc/localtime

date

Fri Jul 31 15:42:09 UTC 2015

```

What am I doing wrong?

----------

## charles17

 *xoJIog wrote:*   

> The problem is that system will modify system time based on /etc/localtime, even if hwlock is set to local time:
> 
> Setting hwclock to local true time:
> 
> ```
> ...

 

Be sure to not conflict with the In-kernel method.

----------

## xoJIog

yes, you are right. in-kernel method was enabled, I disabled it:

```

zgrep CONFIG_RTC_HCTOSYS /proc/config.gz

# CONFIG_RTC_HCTOSYS is not set

zgrep RTC_SYSTOHC /proc/config.gz

# CONFIG_RTC_SYSTOHC is not set

```

But I still see the same problem, after reboot system time is off by value of timezone:

```

hwclock -r --localtime ; date 

Mon Aug  3 19:13:01 2015  -0.958791 seconds

Mon Aug  3 22:13:02 EEST 2015

rm /etc/localtime ; date

Mon Aug  3 19:13:22 UTC 2015

```

----------

## charles17

 *xoJIog wrote:*   

> But I still see the same problem, after reboot system time is off by value of timezone:
> 
> ```
> 
> hwclock -r --localtime ; date 
> ...

 

What do you expect the --localtime option to do?  Reading man hwclock might give you more information.

----------

## xoJIog

I expect --localtime option to tell hwclock that I wish to keep hardware time in localtime.

After I execute command hwclock with --localtime or --utc option, hwclock writes to /etc/adjtime value that defines if hardware clock is kept in localtime or in utc.

As is written in man:

```

--localtime

       -u, --utc

              Indicate which timescale the Hardware Clock is set to.

              The Hardware Clock may be configured to use either the UTC or

              the local timescale, but nothing in the clock itself says

              which alternative is being used.  The --localtime or --utc

              options give this information to the hwclock command.  If you

              specify the wrong one (or specify neither and take a wrong

              default), both setting and reading the Hardware Clock will be

              incorrect.

              If you specify neither --utc nor --localtime then the one last

              given with a set function (--set, --systohc, or --adjust), as

              recorded in /etc/adjtime, will be used.  If the adjtime file

              doesn't exist, the default is UTC.

```

This problem is really frustrating because I have it on multiple servers, but I cannot find anyone who has the same problem which leads me to think that I am doing something wrong.   :Confused: 

FYI: I have tried various combinations of hw clock setting using utc/localtime and none of them worked properly.

----------

## charles17

Doing without the options shows me *Quote:*   

> $ su -c "hwclock && date"
> 
> Password: 
> 
> Tue 04 Aug 2015 09:22:21 AM CEST  -0.672506 seconds
> ...

 

While /etc/adjtime is  */etc/adjtime wrote:*   

> $ cat /etc/adjtime 
> 
> -146.665737 1428911787 0.000000
> 
> 1428911787
> ...

 

Using -r --localtime gives indeed very confusing output: *Quote:*   

> $ su -c "hwclock -r --localtime && hwclock"
> 
> Password: 
> 
> Tue 04 Aug 2015 07:28:18 AM CEST  -0.047371 seconds
> ...

 

----------

## xoJIog

It seems you have your hardware clock set to UTC, I've done the same:

```
cat /etc/adjtime 

-64.430050 1438677666 0.000000

1438677666

UTC

hwclock ; date

Tue Aug  4 11:42:52 2015  -0.443304 seconds

Tue Aug  4 11:42:51 EEST 2015

```

and I've modified /etc/conf.d/hwclock

```
cat /etc/conf.d/hwclock | grep -v "#"

clock="UTC"

clock_hctosys="YES"

clock_systohc="YES"

clock_args=""

```

all is well, until system is restarted

```
reboot

hwclock ; date

Tue Aug  4 11:48:03 2015  -0.914540 seconds

Tue Aug  4 14:48:04 EEST 2015

```

----------

## xoJIog

Ok, the problem is that I was using a machine in virtual environment for tests, it seems that vmware is doing some magic with hardware clock on system restart. I am unable to reproduce this issue on a real server.

Sorry to waste your time with this.

----------

## Goverp

Out of interest, why do you want to run the hardware clock in local time?  That doesn't make much sense, and can cause real problems if your time zone does daylight saving time shifts.

Using local time used to make sense on boxes that dual-boot with Windows, but AFAIK all versions later than XP can be set to handle a UTC hardware clock.

----------

## charles17

 *Goverp wrote:*   

> Using local time used to make sense on boxes that dual-boot with Windows, but AFAIK all versions later than XP can be set to handle a UTC hardware clock.

 and that also wfm with windows 10.

----------

## xoJIog

We use HW clock in local time only because it is more convenient for people that initially configure bios for the new hardware. 

We experienced no problems with daylight savings time shifts even if HW clock is set to local time. Of course this may be due to the face that ntp will run on system startup and correct any errors ( > than 180 seconds ).

However as it was in my initial problem sometimes due to openrc misconfiguration and/or network problem ntp may start before network is available, and that can cause problems.

----------

## mv

 *charles17 wrote:*   

> Using -r --localtime gives indeed very confusing output: *Quote:*   $ su -c "hwclock -r --localtime && hwclock"
> 
> Password: 
> 
> Tue 04 Aug 2015 07:28:18 AM CEST  -0.047371 seconds
> ...

 

According to your commands, the hardware clock data is fetched twice, first interpreting it as local time, and then interpreting it as UTC. What is confusing here, in your opinion?

Concerning your original problem, it seems that something besides openrc is fetching or storing the hardware clock data in UTC. If it is not the kernel itself, I do not know what it is. You should try to configure a very first and a very last process which shows the hardware clock to see whether it is "still" correct. (I am still not sure that it is not the kernel - there are several kernel options concerning various timers which I do not understand and which are perhaps still involved; of course, the kernel has no idea about timezones.)

Just to be sure, please confirm that you are using openrc (and not e.g. systemd), because this would explain the ignoring of /etc/conf.d/*

----------

