It looks like we have the Y2K bug.

I just happened to be looking through clock.c and noticed:

static long
clk_get_secs()
{
        struct clock_ymdhms dt;
        long secs;

        if (rtc_attached == 0)
                return(0);

        rw_rtc(&dt, 0);
        if ((dt.dt_sec  > 59) ||
            (dt.dt_min  > 59) ||
            (dt.dt_hour > 23) ||
            (dt.dt_day  > 31) ||
            (dt.dt_mon  > 12) ||
            (dt.dt_year > 99))
                return(0);

        if (dt.dt_year < 70)
                dt.dt_year += 100;

        dt.dt_year += CLOCK_BASE_YEAR;
        secs = clock_ymdhms_to_secs(&dt);
        return(secs);
}


CLOCK_BASE_YEAR is 1900. Looking at rw_rtc, it looks like the year comes
from two bcd digits in one byte so it seems like the 99 limit is
a hard one and not just something someone thought was a decent sanity
check.

What to do? Who knows what that dallas chip will do? We may be able to
do something like:

  if (dt.dt_year < 99)  /* 99 is somewhat arbitrary */
    dt.dt.year += 2000;
  else
    dt.dt.year += 1900;


and get away with it, but it rather depends on the details of the chip.

1900 was not a leap year but 2000 is. The question is will the clock
roll over to year 00 (as opposed to doing something completely
unpredictable) and if it does, will it think it is a leap year? My
guess is that is is not sophisticated to know about the 100 year and
400 year rules for leap years and will happen to get it right!

It looks like the clock set routine already has a Y2k kludge.

Ian