From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,577c9f9c0cdd76d X-Google-Attributes: gid103376,public From: Marin Condic Subject: Re: Confusing language, was Re: Help help.. please.i am totaly new in ada programing Date: 1999/11/09 Message-ID: <38285C60.B3E2D2BC@pwfl.com> X-Deja-AN: 546520918 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <7vqgs2$lcc$1@nnrp1.deja.com> <38233108.F3540F0@ebox.tninet.se> <806716$i6c2@ftp.kvaerner.com> <807109$8m0$1@nnrp1.deja.com> <38270DC7.86553BB1@pwfl.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: condicma@pwflcom Newsgroups: comp.lang.ada Date: 1999-11-09T00:00:00+00:00 List-Id: Robert A Duff wrote: > That might be true in some cases, but I think that in the vast majority > of cases, Y2K bugs were caused by sloppiness. > Sloppiness, maybe. I never said it was a *good* limitation or an *optimal* design decision - just that it was a very common practice started many years ago in the days of punchcards and COBOL programs for business data processing. It may have been sloppiness, but at least it was Industry Standard Sloppiness. > > After all, I can encode 256 years in one 8-bit byte. So please explain > how encoding a mere 100 years in two bytes saves memory! > Other design criteria were more important. We could have stored dates entirely in binary - even as a floating point number (for fractions of a day). We could have stored dates as Julian dates, etc instead of 08.05.57, etc. It was a more important criteria to use character representation than binary representation for all sorts of human readable/keypunchable issues. So we compromised in the days of astronomically expensive disk space, limited amounts of core and 80 columns on the keypunch card and said "does anybody really think we'll still be using this stuff in 20 to 30 more years?" (The answer at the time was "no" - which goes to show how good we are at predicting the future. But then again, we also thought that the Jupiter II would be out lost in space by now or at least we'd have a manned space oddesy out to the moons of Jupiter in the works. Guess we never thought anybody would cut NASA's budget.) > > Furthermore, show me the documentation that explains that this was an > intended limitation, and the reasons for it. Show me the code that says > "Max_Year: constant Year_Number := 1999; -- ....". I'll bet that in the > vast majority of cases, nobody bothered to write anything like that > down, which supports my "sloppiness" claim. > Dates themselves are inherently sloppy. Hell, if we were designing a calendar today to suite computers, we'd only have 256 days in the year and "2000" would *really* be the start of the new millenium. (You'd have a year "0"). The 08.05.57 date format was commonly used in writing well before the dawn of computers. It was no problem for us humans to deal with the implied "19". The industry accepted this date format for a variety of reasons with the belief that nobody would ever use this software beyond 1999 - and that if they did, they'd know they had to do some kind of conversion. There was an SEP field engulfing it and we all thought we'd be long gone by the time management would commit the cash to fixing it. I suppose we should have written in big block letters on the side of the tape reels "WARNING: Using This Software After 12.31.99 Would Be A Bad Idea!" but I guess we all thought that was intuitively obvious to even the most casual observer. It would be like seeing a sign that read: "WARNING: If You're Ever In A Bar With Human Ears Nailed To The Wall, Don't Pass Out There!" Only a fool would have needed such advice and would likely ignore it anyway. > The techniques needed to properly encode limitations such as the y2K > limit have been known since the 1960's, at least. The fact that they > weren't used is no excuse. Changing the limit from 1999 to 2099 or 9999 > should be a one-line change, and it shouldn't cost millions of dollars > to find that line. > Well, we also knew about Structured Programming back then too, but if I could have sued every ignoramus who wrote spagetti code COBOL programs (complete with "Alter" statements or brought over from assembler by Autocoder!) and left it for me to maintain, I'd be retired somewhere on Palm Beach Island next to the Kennedys. People *could* have come up with ways of doing this - we just hard coded date fields in record structures in COBOL to have 6 characters because that was the way it was always done. It was as simple as that because that was industry practice at the time. Most of it was self perpetuating because you kept inheriting data from older systems that had things coded this way. Nobody wanted to incur the penalties of attempting to convert the old data - which were more than financial. (Everything from inducing bugs all over the place because you didn't know who else might be using the same data to simply pissing off the keypunch clerks who would have to enter the two extra digits and who would not be used to seeing dates in this form.) People made a lot of interesting compromises 20 years ago when working with most of this software. Not all the compromises were driven by technical issues. It was a known limitation that was accepted for lots of complex reasons. Now the folks who really should be slapped (perhaps by some judge who might consider it monopolistic practice?) for any Y2K problems are the ones who, say, released a brand new major software product in 1995 amidst enormous fanfare and press hoopla, and then, say, comes back with a new major software product in 1998 (again with fanfare and hoopla) and tells you "Oh, but did we mention that -95 has a Y2K bug in it? You'd better hurry and buy -98 or your home computer will destroy your life!" (Did I say that out loud? You think "they" might come after me now? ;-) MDC -- Marin David Condic If you hurry you can, for a short time only, still find me at: Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/