From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue, 23 Apr 2013 18:16:01 +0200
From: tlaronde@polynum.com
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20130423161601.GA485@polynum.com>
References: <20130423133003.GB19997@polynum.com>
	<0a19e826eda9d8a748239ae8b38a9cb8@brasstown.quanstro.net>
	<20130423143454.GA461@polynum.com>
	<8c612145eec4c188b76e8740293d345b@coraid.com>
Mime-Version: 1.0
In-Reply-To: <8c612145eec4c188b76e8740293d345b@coraid.com>
User-Agent: Mutt/1.4.2.3i
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: Re: [9fans] Date woes
Topicbox-Message-UUID: 465fd878-ead8-11e9-9d60-3106f5b1d025

On Tue, Apr 23, 2013 at 11:16:37AM -0400, erik quanstrom wrote:
> > But this may affect the way the date is displayed, not the UTC?
>
> are you sure it's not a display issue?  sometimes a double-timezone
> conversion or incorrect timezone conversion can screw up the date.
> fossil uses time(0), which in theory should not conflict.
>

But it is incorrectly setting rtc on exit to the wrong value. So this is
not a display problem. One "time" has the wrong value, /dev/rtc has the
right (until reboot, because wrong is stored---I verified in the BIOS),
and fileserver /dev/time has the wrong.

> > >
> > > 3.  i think timesync(8) may have the information you're looking for.
> > >
> >
> > Thanks for the tip. I have added it to my profile.
>
> make sure you don't have two timesyncs running!  there
> may be one in /rc/bin/termrc or /rc/bin/cpurc.  two at war
> can be a fatal problem.

I will revue all the scripts till my profile to try to understand what's
going on.

Thanks for the advices!
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C