From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 23 Apr 2013 09:34:46 -0400 To: 9fans@9fans.net Message-ID: <0a19e826eda9d8a748239ae8b38a9cb8@brasstown.quanstro.net> In-Reply-To: <20130423133003.GB19997@polynum.com> References: <20130423133003.GB19997@polynum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Date woes Topicbox-Message-UUID: 460140ce-ead8-11e9-9d60-3106f5b1d025 > 1) How can fossil and the system display two different dates? Are they > not using the very same system value? > > 2) Could it be that fossil takes CMOS and then continue on its own or > takes CMOS constantly, while the kernel (?) takes CMOS, then leaves it > alone, correct (wrongly) and counts in software, overwriting the value > only when rebooting? > > 3) Is there something related to Windows "compatibility"? I mean, > Windows stores (stored) local time, and is there a variable that > instructs to correct the CMOS value? 1. check your $timezone environment variable. it could be they are different for fossil and the shell. $timezone is in /env, and there is an independent /env for each process group, so it is entirely possible to have many values on the same system. 3. i think timesync(8) may have the information you're looking for. - erik