Date: Wed, 2 Mar 2005 02:29:08 -0800 From: "Loren M. Lang" <lorenl@alzatex.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-questions@freebsd.org Subject: Re: Received mail timestamp is off by 7 hours Message-ID: <20050302102908.GF30896@alzatex.com> In-Reply-To: <Pine.BSF.3.96.1050301005340.12835A-100000@gaia.nimnet.asn.au> References: <20050228113641.GG1672@alzatex.com> <Pine.BSF.3.96.1050301005340.12835A-100000@gaia.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 01, 2005 at 02:22:40AM +1100, Ian Smith wrote: > 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. Well, I haven't looked into all the details of how FreeBSD does this, but I gaurentee that there is a point where FreeBSD can crash and the clock could be knocked off an hour which wouldn't happen if it's running UTC. Though this window could just be a matter of seconds, I'm not sure. Also multi-booting multiple OS's with it set to local time will always be a problem unless you set only one os to update the clock, and even then, while running the other oses, the update will never happen until you boot into the os which does it. But, in general, it is just a little bit less reliable using local to UTC unless you are not affected by any daylight savings changes like Arizona in the US or, I'm sure, many other places around the world. <snip> -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: CEE1 AAE2 F66C 59B5 34CA C415 6D35 E847 0118 A3D2
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050302102908.GF30896>