Date: Wed, 30 Jul 2014 16:58:18 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Isaac Dunham <ibid.ag@gmail.com>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] hwclock restoring time wrong
Message-ID: <20140730165818.6f5e3688@ncopa-desktop.alpinelinux.org>
In-Reply-To: <20140719141340.GA2042@newbook>
References: <20140716111243.GA2021@newbook>
	<20140716091505.21a8c1f7@ncopa-desktop.alpinelinux.org>
	<20140719141340.GA2042@newbook>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 19 Jul 2014 07:13:41 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> On Wed, Jul 16, 2014 at 09:15:05AM +0200, Natanael Copa wrote:
> > On Wed, 16 Jul 2014 04:12:44 -0700
> > Isaac Dunham <ibid.ag@gmail.com> wrote:
> > 
> > > 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?
> > 
> > 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.
> 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.

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...

> Thanks,
> Isaac Dunham



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---