Received mail timestamp is off by 7 hours
smithi at nimnet.asn.au
Mon Feb 28 15:23:01 GMT 2005
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 at 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.
> > 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!
More information about the freebsd-questions