Subject: [alpine-devel] hwclock restoring time wrong

From: Isaac Dunham <[email-masked]>
Date: Wed, 16 Jul 2014 04:12:44 -0700

Hello,
I've encountered a problem that seems to throw cron for a loop:
hwclock is saving the UTC time, but restoring it as if it were localtime.

I determined this by setting the date manually, then running:
for d in stop start; do date; hwclock -r; service hwclock $d; date; hwclock -r; done
The status changes as follows:

-manual localtime
-real UTC hwclock
hwclock stop
-manual localtime
-manual UTC hwclock
hwclock start
-localtime = manual UTC hwclock, but with the right timezone reported.

I'm not sure if this is a bug in the init script or in busybox.
What would be a good way to check that?

Thanks,
Isaac Dunham

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Natanael Copa <[email-masked]>
Date: Wed, 16 Jul 2014 09:15:05 +0200

On Wed, 16 Jul 2014 04:12:44 -0700

> What would be a good way to check that?

I think the hwclock 'service' has a related configuration in /etc/conf.d/hwclock.

I don't know if the default config is sane though.

-nc

---

---

From: Isaac Dunham <[email-masked]>
Date: Sat, 19 Jul 2014 07:13:41 -0700

> I don't know if the default config is sane though.
It seems to be sane.

Per my reading, hwclock thinks it's setting UTC, so it's a bug in busybox.
At init the boot messages say it's using UTC.

Thanks,
Isaac Dunham

---

---

From: Igor Falcomata' <[email-masked]>
Date: Wed, 30 Jul 2014 09:59:46 +0200

> At init the boot messages say it's using UTC.

Same for me; i had to set clock="local" in /etc/conf.d/hwclock and then
works.

Of course this is a problem if the other osses you use on the same
workstations wants/are configured for the hwclock to be in UTC.

cheers,
I.

---

---

From: Natanael Copa <[email-masked]>
Date: Wed, 30 Jul 2014 16:58:18 +0200

On Sat, 19 Jul 2014 07:13:41 -0700

> At init the boot messages say it's using UTC.

There are some special magic happening first time settimeofday(2) is
called after boot:

>       Under Linux, there are some peculiar "warp clock" semantics
>       associated with the settimeofday() system call if on the very first
>       call (after booting) that has a non-NULL tz argument, the tv argument
>       is NULL and the tz_minuteswest field is nonzero.  (The tz_dsttime
>       field should be zero for this case.)  In such a case it is assumed
>       that the CMOS clock is on local time, and that it has to be
>       incremented by this amount to get UTC system time.  No doubt it is a
>       bad idea to use this feature.

(from http://man7.org/linux/man-pages/man2/settimeofday.2.html)

I don't know if that has any relevance. I have not yet bothered to dig
up what is actually going on... It would be nice if someone could
investigate what is actually happening here. Apparently different
things happens with you call it first time after boot and call it later
again - makes my head hurt...

---