There were a few suggestions made for this problem, but I think some
clarification needs to be made. Two different situations can occur
that could cause the date to incorrectly roll over.
1. The computer is on.
2. The computer is off.
If the computer is on, it does not matter whether or not the hardware
CMOS clock can roll over or not. Most unix operating systems (and probably
most operating systems), maintain their own clock in the kernel of the OS.
The CMOS clock is left to its own devices to do whatever it wants. So, if
your computer is on Dec 31, 1999, and it is running a Y2K unix, then the
kernel clock will roll over. You will not even need to know what the CMOS
clock is doing until your next reboot. With the stability of some unix
boxes, this could be a while. (I usually get about 110 days between reboots
on a FreeBSD box -- and all of the reboots have been due to power failure of
my local utility company).
The next reboot could be a problem -- but actually the BSD box uses the CMOS
clock just to get started. Once the OS is running you can set the date to
anything that fits in time_t (1970-2038). There are a few things that can
be done to fix the problem.
1. Does the CMOS clock work in 2000? This is not the same question as if it
rolls over. That is a separate issue. If the CMOS clocks works, then
have the machine from a cron job periodically update the CMOS clock with
the value of the system clock (kernel clock). If rollover does not work,
this will fix the problem if you need the clock set into 2000. This is a good
thing to do anyway, if the machine runs xntpd anyway since the system clock
would be more accurate than the CMOS clock and it would reduce the amount of
drift that would need to be corrected after a reboot.
You probably could use adjkerntz -a to do this.
2. Nothing works -- CMOS don't roll over and it will work in 2000. No problem.
I have a 486 that does not even have a CMOS clock. When it boots it always
thinks it 1994. The fix is to use the xntpd package. You need a machine to
serve as a time server -- xntpd is both server and client, so it is not too
hard to setup. When your clock-challenged machine boots, you need to reset
the date to something useful as soon as possible. xntpd attempts to slowly
and carefully reset the date. As a result of this, if the time is too
far off 1000 seconds or more (i.e. 16 minutes) it automatically gives up.
So, you need to be more radical in setting the time. ntpdate can set the
time to a more reasonable value. So use ntpdate <ntp server> and follow that
up with xntpd and your machine will have the time of whatever the time
So you need ntp which can be obtained from the port collection or
Now if the computer is going to be off for the roll over, then you can use
slighty different methods.
1. Does CMOS work in 2000? If so, and you know that the machine will be
off (The University I work for is requiring that all machines be powered down
Dec28 through Jan 2) -- then there is no reason why you could not set the
date a head and then fix it with xntpd/ntpdate at boot time. This would be
following suggestion 2 from above.
2. If the clock does not work, then you would definitely need to suggestion
2 from above.
Note that networking is required to use ntp.
I am not sure that you will want a patch or something that enforces some
policy based on time that seems ridiculous. Y2K probably seemed ridiculous
to those who wrote the code that is buggy for us now. But since the unix
Epoch starts in 1970, anytime before then can be mapped to atleast 1970.
: Hi All
: I have a number of servers out there that will understand dates in 2000 no
: problem, but if left to their own devices the date will roll over to 1900,
: not 2000.
: There are lots of utils out there that will fix this for Windows and I
: believe Linux too. Some kind of a daemon or kernel patch that if it sees the
: hardware clock saying something ridiculous it sets the time right.
: I've searched the questions archive and the FreeBSD Y2K statement and
: although this question has been asked I haven't seen it answered.
: Thanks in advance for any comments & suggestions,
: Irvine Short
Configurable Computing Laboratory Research Assistant CB 461 x8-7206
Electrical and Computer Engineering Department Brigham Young University