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

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.