# Clock and timezone problem

## greyspoke

Unti quite recently my computer got on well with its clock.  CONFIG_RTC_HCTOSYS is set in the kernel, my timezone (Europe/ London) is in etc/localtime, my /etc/init.d/hwclock has:

 *Quote:*   

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

 

hwclock is in the boot runlevel.

After a recent upgrade the system clock is no longer getting set correctly, as can be seen from this extract from rc.log (with some added comments) - this was a restart immediately after shutdown:

 *Quote:*   

> 
> 
> ...stuff 
> 
>  * Setting hardware clock using the system clock [UTC] ...
> ...

 

ntpd then corrects the clock back to BST.  Before I changed it to use the -g option (after this first happened) it wouldn't set the time at all as it was too far (1 hour) out.  So it looks like the system clock is getting set wrongly, rather than simply ignoring the daylight saving hour.  Anyhow an hour or so after the above here is what we get:

 *Quote:*   

> timothy@tims_pc ~ $ sudo hwclock
> 
> Password: 
> 
> Mon 10 Sep 2012 19:51:40 BST  -0.812841 seconds
> ...

 

So now both the hwclock and the system clock thought it was 19:51 -ish BST, (presumably they thought it was 18:51 -ish UTC) which was correct.

The system clock appears to be setting itself from the hardware clock wrongly - perhaps reading it and thinking it is saying BST (which it isn't) an so subtracting an hour from it when it shouldn't.  Or something, there are a lot of things about how it ought to work that I don't understand.

Any ideas?

ETA I am running ~amd64 and 3.2.21 kernel

----------

## BillWho

greyspoke,

Check if /etc/localtime was overwritten - this happened to me a couple of times. I symlinked it to my timezone so I can tell if it gets clobbered.

I also have windows installed on this machine so I have clock="local" set in /etc/conf.d/hwclock. The other three computers that are linux-only are set at "UTC.

----------

## greyspoke

Thanks BillWho

Before your post I set clock_hctosys="YES" in /etc/.conf.d/hwclock and now it boots up fine with the correct time showing all through.  Also, my little home server (running x86) is behaving itself time-wise with the same time settings as I had originally, and I have checked that its /etc/localtime and /usr/share/zoneinfo/localtime are identical to those on my computer.  Strangely, the two files are not the same, /usr/share/zoneinfo/localtime is shorter than the one in /etc, the latter is the same as /usr/share/zoneinfo/Europe/London. But as they are binary I cannot fathom what the differences mean, I have just been comparing the hexdumps.  

/etc/init.d/hwclock doesn't seem to have changed in a relevant way between the two computers either, and /usr is mounted in the initramfs so the absence of that can't be the problem.

So it is looking like the problem arises from a kernel upgrade, though that happened a few weeks ago and I must have not noticed the problem???  According to /etc/init.d/hwclock that updates the system clock with timezone info even if it doesn't actually set the system clock, so the cause must be the kernel not setting the system clock to the correct UTC time for some reason.  The kernel appears to be applying a correction as if the hwclock was reading BST - but how does it know any timezone data?

Well that's me stumped.

----------

## Bones McCracker

I have been having this same issue.

I have the same clock configuration (different time zone).  Kernel CONFIG_RTC_HCTOSYS is enabled, and I have the same /etc/init.d/hwclock as the original post.

I have /etc/timezone containing the correct value for me (US/Eastern), and have verified that /etc/localtime is a copy of the correct zoneinfo file for that timezone (/usr/share/zoneinfo/US/Eastern).

Observe:

According to its man page, 'hwclock' always displays local time, and must be set using the local time.  But I want to confirm that hwclock is actually running UTC time, so I manually set it, specifying the '--utc' option:

```
~ # hwclock --set --utc --date "22 Sep 2012 22:58"
```

hwclock displays the correct time

```
~ # hwclock

Sat 22 Sep 2012 10:58:05 PM EDT  -0.685798 seconds
```

I set the system clock from the Hardware Clock.  The system clock displays the correct local and UTC time:

```
~ # hwclock -s

~ # date

Sat Sep 22 22:58:29 EDT 2012

~ # date -u

Sun Sep 23 02:58:31 UTC 2012
```

Everything appears to be in order, so I reboot.

I get a proper message during boot that the system clock is being set from the hardware clock, including the correct UTC time.

```
rtc_cmos 00:05: setting system clock to 2012-09-22 02:59:38 UTC
```

When the system is fully up, I notice my system clock is wrong, displaying the UTC time, labeled as local time (with the system clock's UTC time different by the same offset, of course):

```
~ # date

Sat Sep 23 03:01:29 EDT 2012

~ # date -u

Sat Sep 23 07:01:31 UTC 2012
```

But, the hardware clock is still correct:

```
~ # hwclock

Sat 22 Sep 2012 11:01:52 PM EDT
```

So, it looks to me like the kernel RTC_HCTOSYS is ignoring timezones and assuming the Hardware Clock is running local time.  But, I assume this to be some kind of user configuration error on my part, since this is the only other reference I can find to anyone having such a problem.

----------

## Dr. Strangelove

The misfunctional clock / timezone settings comes from the update to sys-apps/util-linux-2.22.

I opened this bug some days ago. 

Here is the link to the same bug in Arch Linux.

My temporary solution was to keep sys-apps/util-linux-2.21.2 until there is a real fix.

----------

## Bones McCracker

 *Dr. Strangelove wrote:*   

> The misfunctional clock / timezone settings comes from the update to sys-apps/util-linux-2.22.
> 
> I opened this bug some days ago. 
> 
> Here is the link to the same bug in Arch Linux.
> ...

 

Thank you.

----------

## Bones McCracker

I have commented on your bug.  I think the problem may lie elsewhere than hwclock.

Read the entire Description section of the man page for settimeofday() and tell me if the problem described in the last paragraph doesn't sound familiar.

----------

