I've installed the patch for the leap-year bug on our Alpha system, an
Aspen Alpine box running Digital UNIX 3.2C. It offers an improvement,
but I'm not sure I'd call it a fix.
Before installing the patch, I ran a few experiments to see what the bug
looked like. Here's a sample:
- Halt the system; ask the console for the date. It says 15 March.
- Boot UNIX; check the date. It says 14 March.
- Halt the system again; ask the console. It says 14 March.
- Boot UNIX; check the date. It says 13 March.
So it looks like the original bug was that when UNIX read the time from
the console at startup, it subtracted a day. Apparently it also reset
the console's time to match its own, correctly; hence the console's time
was also backed up by a day. The overall effect was that both UNIX's
time and the console backed up by a day whenever UNIX was booted.
The patch for 3.2C is just a new /usr/sys/BINARY/clock.o. I installed
it, and rebuilt the kernel; now I see the following:
- Halt the system; ask the console for the date. It says 15 March.
- Boot UNIX; check the date. It says 14 March.
- Halt, ask the console; it still says 15 March.
- Boot UNIX; it says 14 March.
- Use the UNIX date command to set the date to 15 March.
- Halt the system again; it says 16 March.
- Boot UNIX; it says 15 March.
The new situation is stable, but still wrong; UNIX subtracts a day from
the date when it reads the time from the console, and adds a day when
it writes the date back into the console. It is as if the original bug
in the time-reading code wasn't really fixed, but a complementary bug
was added to the time-writing code. This is disturbing partly for
aesthetic reasons, but also because the original bug didn't appear until
after 29 Feb in a leap year; will the `patched' system's behaviour change
again next year? (A quick test, setting the date to April 1997, suggests
that it will; but the OS is reluctant to accept a year's difference
between the root file system and the console clock, so I may have botched
my test.)
I would be interested to know whether others have seen the behaviour
shown above with the patched system, under 3.2C or other versions of
Digital UNIX. A quick test is to take your system to single-user mode,
check the date, halt it, and ask the console for the date too; if the
console is a day ahead, you have the same problem. Beware time-zone
effects; UNIX sets the console clock to UTC, so compare UNIX `date -u'
with console `>>>date'.
I would also be interested to know whether Digital is preparing a new
patch that really fixes things.
`what /vmunix | grep clock' on my system reveals this revision string
for clock.c:
$RCSfile: clock.c,v $ $Revision: 1.2.19.2 $ (DEC) $Date: 1996/02/07 18:22:09 $
Norman Wilson
High Performance Research Computing
University of Toronto
norman_at_hprc.utoronto.ca; 416/9786358
Received on Mon Mar 25 1996 - 20:17:05 NZST