Mike, It seems funny to me that your dialog progresses from admitting engineer complicity in creating buggy code to then somehow blaming this on managers. I will admit to being unpopular at times with my managers, but I never intentionally wrote code with known barriers (time or otherwise) where it would fail. If I did, then shame on me, not my manager. For my part, I am already worried about Ada's built in Y21000 bug. I won't be around to see it cause problems, but my bet is that it will. That is one reason why I believe Ada's package Calendar to be severely flawed. The other is a failure to distinguish "time" from "local representation of time", but that is yet another contentious issue. All in all, the "engineer-designed" Ada date and time functions leave a lot to be desired, all without any "bad manager" direction -- we engineers can mess it up just fine without management. I wouldn't tout Ada as being a paragon of Y2K compliance. Its package Calendar begs to be implemented as a reflection of the operating systems notion of local time. If that is what is done, then take a look at what happens each year going to and from daylight savings time. It ain't pretty when time goes backward -- it is only luck that there are no transactions at 1am in the morning to cause software confusion and failure. For any Ada application, I strongly recommend that the users code their own date and time packages based on something better than Ada's Calendar. Regards, Steve On Monday, March 08, 1999 1:52 PM, Michael Feldman [SMTP:[log in to unmask]] wrote: > [said John and Dan] > > > > John Apa wrote, > > > > > Y2k is only a problem because it was > > > "discovered", for lack of a better word, late in the game. We've > > > learned > > > that we need to look ahead and write code that won't fail at a > > > predetermined date/time. > > > > John betrays his age -- he must be a younger guy :-) > > > > Being guilty of writing Y2K-noncompliant code 30 years ago myself (for > > different employers), I can vouch that the problem was not "unknown" and > > did not need "discovery" later on: we all knew what we were doing, > > namely, cutting corners to get those programs to run in the teensy > > memories of the day. We knew the code wouldn't work on 01jan2000; what > > we *didn't* know was that our software would still be in use then! > > Right. I've written my share of concompliant code too. I can recall > seeing trade-press articles (Datamation, etc.) in the early _seventies_ > referring to the Y2K problem (though of course we didn't call it that). > Naturally, not many took it seriously then. > > I refuse to call this Y2K thing a "bug", as we see so much in the press > today. It is not a bug - the software is meeting its specs and working > exactly as it was engineered to work. > > I hold that the Y2K "problem" has us in such a panic now because - fully > alert to it at least 10 years ago, when we _knew_ memory prices would be > dropping like crazy - managers made conscious decisions not to fix > the software in a timely manner, on their own watch. Better to put it > off on the next guy's budget. > > Granted that 20 years ago we didn;t think a lot of that software > would still be alive today, but > > - 10 years ago we had good reason to predict that it might be; > - 10 years ago there was no excuse on earth to build noncompliant > PC BIOS versions, etc. > > Bugs are unintended. This so-called "bug" is an unintended consequence > of a good-faith engineering decision that went sour not because of a > software failure but because of a monumental management failure, the > failure to take responsibility till it's (almost) too late. > > > *All* date-based code will eventually "fail at a predetermined date/time" > > -- it's just a question of how far out the failure date is; back then, we > > thought 3 decades was quite long enough. Should we be writing code that's > > Y10K compliant now? :-) > > I agree entirely. > > What does this have to do with Ada? Not very much, except that we do > happen to have a library of Y2K-compliant calendar services. There is > no magic, though. Nothing forces developers to use those services. > So let's not be too quick to brag, folks - there really is not all > _that_ much to brag about. > > Now, if we could show that _managers_ of Ada-based projects tend > to be more foresighted than others, well, that might be a point of > pride. But is it true, and how would we know? > > > An interesting aspect of all the current Y2K testing is that it > is turning up many instances - often in commercially popular software - > of the leap-year bug, which rejects transactions slated > for Feb. 29, 2000. This one is, in fact, a bug. It shows the monumental > illiteracy of many developers. If you're gonna code date routines, > you really oughta look up how to tell if a year is a leap year. > My freshmen know the algorithm. > > It's not that hard to find - try the encyclopedia. > > > C. Daniel Cooper =========v=======================v > > Michael Feldman > ------------------------------------------------------------------------ > Michael B. Feldman - chair, ACM SIGAda Education Working Group > Professor, Dept. of Electrical Engineering and Computer Science > The George Washington University - Washington, DC 20052 USA > [log in to unmask] - 202-994-5919 (voice) - 202-994-0227 (fax) > http://www.seas.gwu.edu/faculty/mfeldman > ------------------------------------------------------------------------ > "Whaddya mean, the Air Traffic Control system won't run > without a Microsoft browser??!!!" > -- political cartoon, Washington Post, Jan. 3, 1998 > ------------------------------------------------------------------------ > Ada on WWW: http://www.acm.org/sigada/education or http://www.adahome.com > ------------------------------------------------------------------------