return from DST did not worked
smithi at nimnet.asn.au
Mon Oct 31 15:32:45 UTC 2016
In freebsd-questions Digest, Vol 648, Issue 1, Message: 14
On Mon, 31 Oct 2016 09:24:11 +0100 Matthias Apitz <guru at unixarea.de> wrote:
> El d?a Monday, October 31, 2016 a las 07:51:58AM +0000, Matthew Seaman escribi?:
> > Matthias is correct that having the BIOS clock a.k.a. the CMOS clock
> > running UTC is the preferred setting, but even if you don't the system
> > will still track daylight savings time changes for you.
Indeed; I've (ahem) preferred using local time since '98 and had no DST
issues I can recall - but on systems running 24/7, including laptops.
> > There's a cronjob in /etc/crontab that runs adjkerntz(8). That should
> > get run every half hour between midnight and 5.00am each night, which
> > will detect that it needs to update the CMOS clock on the two occasions
> > each year when the clocks change...
> > If the OP doesn't leave his system running overnight, then that will not
> > happen, and the time will get set an hour out on reboot in the morning.
> > If this is what happened, then it should suffice to set the kernel clock
> > to the correct time (ie. turn off ntpd(8), use date(1) to get the clock
> > within a few seconds of correct, start ntpd(8) and leave it to synch
> > properly, then run 'adjkerntz -a')
> > adjkerntz(8) also should get run as a daemon at system boot if your
> > system is set to use local CMOS time, which sets the kernel clock from
> > the CMOS clock at bootup, and sets the CMOS clock from the kernel clock
> > on shutdown.
And you must remember to run 'adjkerntz -i' when in single user mode :)
> I have had localtime in CMOS, and not UTC. And due to the fact that the
> system (a netbook) was off betwwen 0 and 5 the job in /etc/crontab did
> not got fired. I changed it now to UTC in CMOS (running tzsetup(8) and will
> wait for the next DST...
You didn't say, but I guess you've removed /etc/wall_cmos_clock ?
More information about the freebsd-questions