ML> The cheap RTC chips used in the AT, and in most PCs since, don't
ML> even know what century it is, which is the source of this
ML> discussion.

Actually, the source of this discussion was my very simple question as 
to whether there was any version of OS/2 which would choke on 01 January 
2000. After having some smoke blown up my ... er, in my face concerning 
my old equipment, RTC hardware, and alleged "bugs" in my BIOS, Jonathan 
de Boyne Pollard answered my question.


ML> Ian's claim that "the RTC/CMOS itself is good up to the
ML> year 9999" is due only to his belief that there was never a design
ML> error ("bug") in that part of BIOS that read the RTC and handled the
ML> century byte in CMOS.

Not true. Why would you prefer people to believe that?


ML> My experience is that even with the "fixed"
ML> BIOS in my newest PC (that recognizes 1-1-2000) IBM took the easy
ML> way out and inserted the "window" fix instead of going back and
ML> redoing the whole RTC firmware. (I can't speak for other BIOS
ML> builders, but there is an easy test to check for how the bug was
ML> fixed in your machine: boot to real DOS, set the system clock to
ML> 1-1-2080, and reboot.  If you get 1980, your BIOS was "fixed" with
ML> the window!)

My BIOS _correctly_ reports that the date is 2080. I believe you were 
telling me that this correct reporting of the date was because my older 
BIOS' is buggy. The newer BIOS', such as yours, which have fixed this 
"bug" report the wrong date on 2080.

Do I have that straight now? Very convincing.


ML> However, even assuming a better BIOS fix that won't die at the end
ML> of 2079

A "better" fix? Is there something wrong with the current "fix"? _My_ 
old "buggy" BIOS is going to correctly report the date in 2080 and 
beyond. Just out of curiosity, where's the bug? What makes you think 
that a BIOS which _correctly_ reports the date in 2080+ needs to be 
"fixed" so that it _won't_ correctly report the date in 2080+?


ML> If the firmware for this RTC doesn't
ML> know the 400 rule for century leap years (the DOS CLOCK$ driver
ML> didn't know it as of 1991, the last time I disassembled one), it
ML> will display March 1, 2100 as February 29th.  From then on, the
ML> clock will be a day behind the real world until the day it displays
ML> as February 29, 2200, which will be March 2, 2200 in real time!  It
ML> will then be two days behind the rest of the real world until the
ML> next century rolls around, etc.  Of course, it won't lose another
ML> day during the years divisible by 400, but it will never be correct
ML> after that first error!  Under these assumptions, it will be wrong
ML> on all days, not just during century years, after February 28, 2100
ML> :-(.

I envy you your computer. I've never seen a computer as maintenance-free 
as yours. I can only imagine the technology which has gone into your 
CMOS battery... [:*)

Sarcasm aside, you can spend a lot of time redesigning the RTC to 
account for the 400 year rule (why bother?) and taking into account the 
1000 year rule (why bother?) and to automatically adjust for all those 
additional multi-millenial rules that you've not mentioned yet (why 
bother?) as well as the occasional leap second adjustments (why bother), 
but why bother? Why bother overdesigning an RTC which is usually only 
accurate to within several seconds a day (+6min/yr @ 1s/d) and for which 
the battery needs to be replaced every five or six years?

It's a tempest in a teapot!! Why bother worrying about a once-in-a-
century adjustment on a device which needs _constant_ adjustment 
anyway!?! This topic, and the oversensitivities which accompany it, 
approach the ridiculous!

It's my _considered_ opinion that discussion of alleged Y2K-related 
hardware "problems" and "bugs" is little more than an excuse for self-
important, non-professional (as well as unprofessional) propeller-heads 
to stir up the chamber-pot.

Not meaning you, of course. You are well known in these parts for being 
very helpful and knowledgable on many facets of hardware and software 
(particularly of OS/2) and of freely and openly sharing your knowledge 
equally with everyone.


ML> Of course, those future system architects and programmers who design
ML> the future PC (including its firmware) along with the future
ML> software architects and programmers who design and implement the
ML> super operating systems that will run on the super PC, may do
ML> everything right the first time.  But I don't think that I will wait
ML> around to see if it actually happens :-).

Perhaps atomic clocks with a well-shielded thermo-electric power 
source...? [;)

Nothing's perfect. My worries tend more toward issues of _real_ import 
to the industry and my hobby, such as those regarding the limitations of 
ATA. And of USB -- the clone PC implementation of the C=64 peripheral 
interface.

Take care and TTYL.

---
 þþ Wanna see me make bubbles with my spit?                        

--- AdeptXBBS v1.11y (FREEWare/2)
382/92