reintom@rocky2.UUCP (Tom Reingold) (12/02/86)
[]
If anyone can answer the following question, I would be
grateful.
When we leave our PCs on overnight, the date does not always
change, although the time is kept current. I have not
figured out how to duplicate so I don't know exactly why it
happens only sometimes.
It used to happen only on our Zenith 158 running Zenith's
MS-DOS 3.1. Now it also happens on our IBM PC/XT running
IBM's PC-DOS 3.1.
What is going on?
--
########################################################################
Tom Reingold -- Rockefeller Univ, 1230 York Av, NY 10021; (212) 570-7709
UUCP: {seismo|philabs|phri|harvard|ihnp4}!cmcl2!rna!rocky2!reintom
ARPANET: reintom@rockefeller.arpa <<<<<<<->>>>>> BITNET: REINTOM@ROCKVAXsmvorkoetter@watmum.UUCP (Stefan M. Vorkoetter) (12/02/86)
Ditto on my PCjr running PC-DOS 2.10. No real problem though, I just reboot in the morning and it gets reset from the addon hardware clock.
brown@nicmad.UUCP (12/02/86)
In article <289@rocky2.UUCP> reintom@rocky2.UUCP (Tom Reingold) writes: >When we leave our PCs on overnight, the date does not always >change, although the time is kept current. I have not >figured out how to duplicate so I don't know exactly why it >happens only sometimes. > >It used to happen only on our Zenith 158 running Zenith's >MS-DOS 3.1. Now it also happens on our IBM PC/XT running >IBM's PC-DOS 3.1. > >What is going on? A bug in the DOS program. Something about it requiring a keyboard input before the date will be changed. I don't know all of the details, but also heard that IBM/Microsoft wasn't going to fix it in any of the current DOS versions [3.10/3.20]. Your only choice is to reboot the system to read the, hopefully installed, time clock chip. -- ihnp4------\ |------------------------| harvard-\ \ | terminus: | Mr. Video seismo!uwvax!nicmad!brown | The clearing house for | topaz-/ / | rec.arts.drwho | decvax------/ |------------------------| terminus-----/
psfales@ihlpl.UUCP (Peter Fales) (12/04/86)
> When we leave our PCs on overnight, the date does not always > change, although the time is kept current. I have not > figured out how to duplicate so I don't know exactly why it > happens only sometimes. Just a guess, but does it only happen when the PC is not used for two days (i.e. over a weekend)? This may not be quite correct, because I don't remember all the details, but the basic idea is this: The way DOS keeps track of time is to increment a counter each time the timer interrupt comes in (18 times per second). Then the DOS routines convert this to the actual date and time. When the timer interrupt notices that a midnight has been crossed it simply sets a flag - it is the responsibility of the next call to the DOS time function to notice this flag and increment the date. However, if the DOS function is not called for a whole day (i.e. the time crosses two midnights) the flag will be set twice but the only noticed (and cleared) once, resulting in a date that is one day behind. Peter Fales ihnp4!ihlpl!psfales
roy@gitpyr.gatech.EDU (Roy Mongiovi) (12/04/86)
The reason for the date not changing may be twofold. If you are using
DOS 2.0, there is a bug, but first let me describe how it can happen
on all PC's.
When IBM designed the timer tick interrupt that keeps track of the time
of day on the original PC (and hence, when they set the standard for
everyone else), they did it in a really shoddy way. The BIOS keeps a
count of the number of timer ticks since midnight. When the PC sees
that the tick count has gone past the number of ticks in a day, it
resets it to zero and sets a byte to one. This byte is a flag that
says "the tick count has rolled over," not a count of the number of
times it has rolled over. Now, in normal practice DOS reads the time
from the BIOS, which return and clears the rollover flag, and notes
that the date has changed. But if you leave your PC on for more than
a day without causing DOS to access the date, the rollover count gets
set to one twice (which of course doesn't help much), and a day is
lost. Leave it on over the weekend, and two days are lost.
The bug in 2.0 was that DOS would get the date and time whenever disk
I/O occurred so that it could record the modification date/time of the
file, and it would neglect to record the rollover flag. So if you
happened to be accessing disk at midnight, the BIOS would clear the
flag but DOS would ignore it, and a day would be immediately lost.
Now ask me why IBM allocated an entire byte but didn't have the brains
to increment it rather than just setting it to one....
Roy
--
Roy J. Mongiovi Systems Analyst Office of Computing Services
Georgia Institute of Technology Atlanta GA 30332. (404) 894-4660
...!{akgua, allegra, amd, hplabs, ihnp4, masscomp, ut-ngp}!gatech!gitpyr!royrde@ukc.ac.uk (R.D.Eager) (12/05/86)
Just to clear up a slight error in a previous article.
The date rollover in DOS problem; is actually TWO problems.
First, as someone said, the flag in the BIOS just says that a new day
has started, not how many new days. Thus a machine that is unused for a
day will 'lose' a day.
Second, the IBMBIO.COM code (the BIOS interface) has a bug which is
certainly present in DOS (MS and PC) version 2.xx. I am pretty sure it
is fixed in 3.xx; I looked for the faulty code and it was no longer
faulty. This bug is that there are *several* calls to the BIOS timer,
but not all are to get the date/time for DOS (those that are work
OK). The other calls are nothing to do with disk file date/time (they
are done by the calls just mentioned) but with a two second timer used
for disk optimisation. In a nutshell, the disk driver tries to
compensate for the lack of a door latch status bit by saying that a disk
can't have been changed for another if it was accessed in the last two
seconds (thus allowing directory/FAT cacheing). The bozo who wrote this
bit just ignored the rollover bit! Thus, if the first BIOS call after
midnight is to get date/time, fine. If it is a disk access, it will
almost certainly get the date wrong....
--
Bob Eager
rde@ukc.UUCP
rde@ukc
...!mcvax!ukc!rde
Phone: +44 227 66822 ext 7589