Received mail timestamp is off by 7 hours

[Ian Smith]

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. 

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