Running "adjtimex --compare" fails in year 2000, due to y2k bug.  The bug
has to do with the interpretation of the year value stored in CMOS on
standard PC motherboards.  The year value in CMOS has only two digits, and
code that does "<yearvalue> + 1900" fails in year 2000.

Here is a context diff which fixes the problem, (but note that your web
interface may mess with the formatting).  If it would be useful, I can
supply an adjtimex.spec file that uses this patch and includes a changelog
entry.

*** adjtimex.c.orig     Sun Jan  2 11:51:46 2000
--- adjtimex.c  Mon Jan  3 00:24:39 2000
***************
*** 409,416 ****


        tm.tm_mon--;            /* DOS uses 1 base */
!       tm.tm_wday -= 3;                /* DOS uses 3 - 9 for week days */
        tm.tm_isdst = -1;               /* don't know whether it's daylight
*/
  #ifdef DEBUG
        printf (" mday=%d  mon=%d  wday=%d  year=%d\n",
              tm.tm_mday, tm.tm_mon, tm.tm_wday, tm.tm_year);
--- 409,429 ----


        tm.tm_mon--;            /* DOS uses 1 base */
!       tm.tm_wday -= 1;                /* Was 3, but 1 appears to be
correct */
        tm.tm_isdst = -1;               /* don't know whether it's daylight
*/
+
+       /* Some machines have a century register, but not all do and the
+        location varies.  Instead of trying to use it, follow the
+        advice of the X/Open Base Working Group (which also matches
+        what the hwclock program from the util-linux package does):
+
+        "if century is not specified, then values in the range
+        [69-99] refer to years in the twentieth century (1969 to 1999
+        inclusive), and values in the range [00-68] refer to years in
+        the twenty-first century (2000 to 2068 inclusive)." */
+       if (tm.tm_year < 69)
+         tm.tm_year += 100;
+
  #ifdef DEBUG
        printf (" mday=%d  mon=%d  wday=%d  year=%d\n",
              tm.tm_mday, tm.tm_mon, tm.tm_wday, tm.tm_year);