> > From: Bob Leif, Ph.D. > > > > Two questions. 1) Was this date package written in Ada? And 2) If it was > > written in Ada, how much work did it take to fix? I suspect that there > > may > > have been other Year 2K problems in Ada. However, the ease of maintaining > > Ada made the effort to repair minimal. Minimal effort projects are seldom > > reported because they do not change the budget. Actually, the Year 2K > > problem is NOT the disease. If Year 2K problem is significant, it is a > > symptom of poorly engineered software. I wrote the fix. I added a sliding window for 2-digit date interpretations, that can be changed by the application. I fixed the get_from_text routines to accept either 2-digit or 4-digit dates (with the 2-digit dates being interpreted based on the sliding window). I also added 4-digit output routines. Even with the bad spec and implementations mentioned below, it was a simple matter to make these changes. The hardest part was figuring out what changes to make that would be least obtrusive (if there existed any code using the package), and most likely to be correct even if used "stupidly". Note that the spec for dates.a is a very *bad* abstraction. It was only a toy interface used for the "Getting Started with VADS" document, and was included as source only so the user could "follow along" with the documentation. It was put into "publiclib", where there was explicitly NO Verdix (originally) or Rational (later) commitment to correctness. The implementation is so brain-dead, I was embarrassed to work on the code body -- for example, subtraction of two dates is done by incrementing the lesser date until it equals the greater date, incrementing the count of days with each iteration of the loop. The spec is so bad an abstraction (really it is a non-abstraction) that I cannot believe anyone actually ever used the package outside of the Getting Started document To top it off, the package itself was *NOT* Y2K-non-compliant per se. It was only that the package *might* have been *easily* used in a Y2K-non-compliant manner that caused the problem. The package could have been used in a Y2K-compliant way by any application that did a little work when calling it. That is the problem with Y2K-compliance and "parts of a program" (including the choice of language) -- they simply are inconsistent concepts. Only an application can be Y2K-compliant or Y2K-non-compliant, not any particular part of an application. In spite of disclaimers, poor abstraction, and poor implementation, crazed Y2K-zealots were having major problems with this "non-compliant" package in VADS. Essentially they concluded that all of VADS was non-compliant. Telling them to simply delete the package from their release did not weaken their resolve. Eventually it became clear that rather than try to talk sense into these people, it was easier and less time consuming to simply put out a version of the package that was more likely to be used in a Y2K-compliant manner by "dumb" applications (which by my reckoning are the only ones that might use the package). Hopefully this is the last discussion on this aspect of Y2K-compliance. I personally find it all a bunch of hype over nothing. Some things will break, but few will break on Jan 1, 2000. Most will break a year or two before that or in the ensuing year. For example, when your new charge card came with a 02/01 expiration date, that was an opportunity for a Y2K failure. Similarly, when you go to renew your car license in Jan 2001 from the last registration that was done in 1999, that is an opportunity for a Y2K failure -- I can envision them getting 2000 right, but screwing up on subtracting 99 from 01. There are all sorts of ways to make programs that break, and Y2K is only one of them. In the end, all critical things will work (because people have checked), and many non-critical things may break (I consider the IRS non-critical unless I get audited). It is a great opportunity for COBOL, FORTRAN and assembly code programmers to make a lot of money if they can stand reverse-engineering some of the worst code ever written. The C-code guys are good until 2032 :-). Regards, Steve Steven Deller, Apex Ada Marketing [log in to unmask], (410) 757 6924 Rational Software Corporation, http://www.rational.com