Re: Question: How will the Year 2000 bug impact your work?

info@sundialservices.com (Sundial Services) wrote: >In article <325E9B5F.752A@eagle.cc.ukans.edu> Matt Bovee <mbovee@eagle.cc.ukans.edu> writes: >>I am currently preparing a graduate paper on the impact of the Year 2000 (Y2K) >>bug on databases, database applications, and database management. Specific areas >>of interest to me and the group to whom it will be presented are: >... >>If you work with one or more of the above, and have specific examples of how the >>Y2K bug is going to affect you, the database(s), or the way you do work, and how >>you (or others) are specifically addressing the problem, would you please >>respond either on the NG or via e-mail (address below, too)? >>If you don't know about Y2K, but can at least give me an idea of how data with >>date fields or date information is used in any of the particular specialties >>above, whether your particular area of databasing uses primarily two-digit date >>fields, and the potential impact of having the year field "roll-over" to "00", >>that would be just as good. >>Any and all assistance will be most helpful. Thanks, >I cordially suggest that perhaps we should begin by defining and exploring >what we are talking about. For example, you appear to take for granted that >there -is- a "year 2000 bug," when in fact all of the databases whose groups >you posted to (I believe) contain intrinsic support for date/time values with >no limitation as to century. >The essence of the too-widely-popular "bug" as we've all heard about it, is >that a computer cannot distinguish between 1900 and 2000, when in fact a >database date/time field type most certainly -can.- Furthermore, even the >most basic field validity-checks can enforce a rule that dates prior to some >cutoff (e.g. 1910) cannot be entered; and "triggers" can be used to >automatically adjust entered values. And so on. >As a matter of fact, the -only- systems that could truly be affected by a >digit inaccuracy would be those few COBOL systems whose designers were so >short-sighted to code dates with two digits. Dates were, and are, such a >problem that all of the shops I know of not only wrote four-digit dates to >begin with, but wrote a large boatload of Assembler routines specifically to >handle dates. When databases supported dates and times better, we all >breathed a sigh of relief. That was, like, in the 1970's... :-/ >Anyhow, to wind up, I do think that two-digit date input, although the date >may be reliably translated into some distinguishable century, is something >that designers of products like Access, etc. will provide much better support >for. I think there is, even now, the need for an option to allow the user to >specify the two-digit year-value below which the 21st century should be >assumed. >So as you craft your paper, be careful to explore just what you mean by "the >bug," and be wide-eyed about how you interpret it. If you consider it a "bug" >that "2/2/0" might mean 1900 (-and- be stored as 1900 with no ambiguity), then >the impact AND the solution of that problem is vastly different than that >which may be faced by our poor COBOL friends, if they and their problems >actually exist in the quantity supposed. I think you underestimate the problem with 2 and four digits in our beloved computer systems. There are examples which show that even 4 digits year systems have problems, e.g. change in WINDOWS 3.1 the date to 31-12-1999/23:59 and turn off your computer. Restart the system after a few minutes and you will end up with a system date of 1-1-1980/00:02. All calculations that include the system date will be wrong. What I want to say is that fixing the problem (2digit-year calculation to 4-digit-year calculation) is not a big deal, but finding all (!!!!) occurences of short-sighted date storing and calculating is the real problem (even if you think that the underlaying database will handle the problem). There will be several companys whith big problems when we change to the Year 2000! Regards Christian ***************************************** * Christian P. Schucan * * ETH Zurich, CH-8092 Zurich * * Tel. 01/632 72 84 Fax. 01/632 11 72 * * e-mail: schucan@inf.ethz.ch * *****************************************