Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!yale!quasi-eli!cs.yale.edu!spolsky-joel
From: spolsky-joel@cs.yale.edu (Joel Spolsky)
Newsgroups: comp.windows.ms
Subject: Re: Bug with Screenpeace
Message-ID: <27574@cs.yale.edu>
Date: 4 Dec 90 04:32:25 GMT
References: <1990Dec3.162131.27441@amd.com>
Sender: news@cs.yale.edu
Distribution: usa
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Lines: 26
Nntp-Posting-Host: zoo-gw.cs.yale.edu
Originator: spolsky@suned.CS.Yale.Edu

In article <1990Dec3.162131.27441@amd.com> wluo@brahms.amd.com (Wilbur Luo) writes:
>After some testing, apparently there is a bug with screenpeace.
>If you were to leave your computer on over the weekend without touching
>it until monday (i.e., leave it friday afternoon, and come in monday)
>, the date would be wrong. It would say Saturday. 

This is not a bug with ScreenPeace. It is a bug with MS-DOS. It has
been a known bug with MS-DOS since about 1981...

The bug is that if you do not query the time for two date changes,
only one date change will occur. The problem results because when the
timer interrupt, keeping track of seconds passing, wraps around from
2359 to 0000, a flag is set to indicate that the date should be
incremented. The date is not actually incremented until you actually
check the time, presumably so that timer interrupts take a fixed
amount of time, even at midnight, to complete. I guess somebody
thought that this would be important for real-time systems. The
problem is that as there is only one bit reserved to indicate a date
change, _two_ date changes are not treated correctly unless there is
at least one clock read between them.

One fix would be to leave the windows Clock running which should query
the time occasionally and prevent this problem. 

Joel Spolsky
spolsky@cs.yale.edu