Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!ogicse!pdxgate!qiclab!leonard
From: leonard@qiclab.scn.rain.com (Leonard Erickson)
Newsgroups: comp.os.msdos.misc
Subject: Re: Midnight Bug
Message-ID: <1991May17.005709.14225@qiclab.scn.rain.com>
Date: 17 May 91 00:57:09 GMT
References: <1991May5.175313.21025@athena.mit.edu> <1991May7.012810.8934@serval.net.wsu.edu> <19093@sdcc6.ucsd.edu> <1991May13.180754.25187@eng.ufl.edu>
Organization: SCN Research/Qic Laboratories of Tigard, Oregon.
Lines: 29

jy@wasp.eng.ufl.edu (Jim Yousse) writes:

>Does anyone know about the Midnight Bug in DOS, where the clock does not
>register a date change when passing midnight?  We have a user here who
>leaves her machine on continuously, and every now and then it will lose
>a day.  We're pretty sure this is the midnight bug in action.  We've heard
>of fixes for this, but don't know where to get one.  Any suggestions?

Well, unless you have an *old* version of DOs, it works like this:

At midnight, the TimerCount (in the BIOS work area at 0040:????) is
reset to 0. And another memory location in that area is *set* to 1.
(Not incremented, *set*).

The next time anything asks DOS for the date or time, DOS sees the "flag"
is set, clears it, and increments the date by one. 

So you only lose a day if nothing asks DOS for the Date or time for
*two* days. 

The solution is to install *something* that keeps checking the time,
say a menu program with a clock display in the corner. Or even a TSR
that displays the time on screen somewhere.

Last I heard, Microsoft had no intention of fixing this.
-- 
Leonard Erickson			leonard@qiclab.uucp
personal:	CIS: [70465,203]	70465.203@compuserve.com
business:	CIS: [76376,1107]	76376.1107@compuserve.com