Date: Tue, 1 Mar 2005 02:22:40 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: "Loren M. Lang" <lorenl@alzatex.com> Cc: freebsd-questions@freebsd.org Subject: Re: Received mail timestamp is off by 7 hours Message-ID: <Pine.BSF.3.96.1050301005340.12835A-100000@gaia.nimnet.asn.au> In-Reply-To: <20050228113641.GG1672@alzatex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 28 Feb 2005 03:36:41 -0800 Loren M. Lang wrote: > On Mon, Feb 28, 2005 at 12:58:17AM +1100, Ian Smith wrote: > > On Sun, 27 Feb 2005 03:10:12 -0700 Pat Maddox <pergesu@gmail.com> wrote: > > > > > Alright, I got it all working now. Not sure how to change the time > > > zone with config files, so I just used sysinstall to change it to MST > > > (time zone is arbitrary, but since this is the zone I live in, it's > > > convenient for me). Then I used ntpdate to sync it, and it's working > > > well now. > > > > > > Thanks for pointing that out to me. I just thought that CET was central time :) > > > > Yes sysinstall's as good a way as any, it'll set your timezone and also > > let you choose between running with a UTC or local time CMOS clock. Or > > you can manually tun tzsetup(8) and create (or not) /etc/wall_cmos_clock > > .. see adjkerntz(8) > > > > Take little notice of people opining that you must or even should run > > CMOS UTC time; that's entirely up to you. I've always preferred local > > time CMOS clocks personally; sysinstall creates /etc/wall_cmos_clock and > > cron runs 'adjkerntz -a' halfhourly at times when daylight savings time > > might come or go in your zone, and that's always worked fine here. > > The reason using UTC for the cmos clock is that it never changes like US > daylight savings does. Now if your timezone doesn't ever need to be > pushed forward or backwards then it won't be a problem, but otherwise > evertime the system boots up, it has to determine if the cmos time is > correct or needs to be adjusted. A UTC time will always be correct and > can be turned exactly into the correct time at the moment. I think that > if FreeBSD crashed just after it booted up and adjusted the hour forward, > then on the next reboot, it would adjust it another hour forward. In > general, it is just harder to manage. Even worse would be my Quad boot > system with Gentoo Linux, FreeBSD, OpenBSD, NetBSD. If I used local > time for my cmos clock then every daylight savings change, each os would > adjust the clock independently and I'd be 3 hours off. I don't believe that's correct Loren, at least, not for FreeBSD anyway. adjkerntz -i when run on entering multi-user mode does not set the CMOS clock, it just reads from it to update the kernel clock if need be. If /etc/wall_cmos_clock exists, it knows to add the timezone offset to move the kernel clock to UTC; otherwise it takes CMOS clock time as UTC. Only adjkerntz -a (run from cron) makes adjustments on daylight savings time boundaries, and that's the only time it will update the CMOS clock. If running local time CMOS (/etc/wall_cmos_clock exists) then adjkerntz -i continues running in background the whole time. Only on a (proper) shutdown does init send a SIGTERM to adjkerntz, which then updates the local CMOS clock (if necessary) from the then kernel clock. If the system crashes without proper shutdown (eg power + UPS failure) then any changes made to the kernel clock during uptime aren't updated back to the CMOS clock which is otherwise free-running, that's all. At least, that's my reading of adjkerntz(8) and experience over 7 years. I did read much of the relevant code back in 2000 on a 2.2.6 system, but admittedly haven't checked since then to see if any of that's changed, and since it's a full-time server, haven't had to consider multi-boot. I also run local time on my 4.5-R laptop, _very_ rarely booting Windows, and haven't struck any problems with CMOS time changes in three years. Disclaimer remains: > > The only thing to watch running wall_cmos_clock is that if you boot to > > single user mode, before /etc/rc has run 'adjkerntz -i' the system will > > assume CMOS is UTC, so any files then modified show timestamps in UTC > > (discovered the hard way in Jan 2000 on a box with a broken y2k BIOS :) I should mention that Jean-Marc Zucconi gave me lots of good pointers in 2000 re fixing our system to handle that crook y2k BIOS. He suggested C patches, but I wimped out by adding some date commands to /etc/rc :) Sorry if this is getting a bit long .. it really comes down to personal choice; I sure wouldn't want to dissuade anyone from running Zulu CMOS! Cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1050301005340.12835A-100000>