From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 23 Apr 2013 19:36:02 +0200 From: tlaronde@polynum.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20130423173602.GA406@polynum.com> References: <20130423133003.GB19997@polynum.com> <0a19e826eda9d8a748239ae8b38a9cb8@brasstown.quanstro.net> <20130423143454.GA461@polynum.com> <8c612145eec4c188b76e8740293d345b@coraid.com> <20130423161601.GA485@polynum.com> Mime-Version: 1.0 In-Reply-To: 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: 4678cf18-ead8-11e9-9d60-3106f5b1d025 On Tue, Apr 23, 2013 at 12:59:22PM -0400, erik quanstrom wrote: > > are you sure that these flags might not be part of the problem? > there is no clear answer to the question, "is rtc clock in local time > or gmt?" > > -r synchronize to the local real time clock, #r/rtc. > > -L used with -r to indicate the real time clock is in > local time rather than GMT. This is useful on PCs that > also run the Windows OS. Found! In termrc: TIMESYNCARGS=(-rLa1000000) I guess this is a default what we should document somewhere. Or, reversely, do not make it a default, and document how to change if local time is stored. Something still not clear: date (shell) was using the incorrect time (local when RTC was in UTC), but fileserver was using correct that is fileserver took the rtc but did not apply what aux/timesync applies. Because fossil is mounted _before_ since termrc is served by fossil? -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C