Re: HELP! YEAR 2000 BUG: How will it affect you?

Matt, I'm not sure which bug you are referring to...because I know of two major problems. Problem one is date match on 2 digit date fields. Most database applications allow you to set the century, and also store dates including the century. <<Bug as I see it...tell me if I'm correct because your message was vague>> The real problem I know about has to do with the day of the week. Normally, leap year is every 4 years. However, because the earth takes 365 days 5 hours and 46 minutes to circel the sun, adding a day every four years overcompensates by a few minutes. To compensate for this overcorrection, the Gregorian calendar skips leap year in centuries divisible by 400. All the bios' written for PC's have a February 29th in the year 2000. That throws off the date math and the day of week. I presume this will be a simple patch. The 400 year rule is an easy implementation, and presuming the world continues to use the Gregorian calendar, then the software vendors will have to issue a patch to their code. This couldn't be too difficult since they already have to account for leap year as a rule anyway. I use several fuzzy search and neural network routines across several gigabyte databases that use dates heavily. All these databases are filled with real estate data that includes everything from listing dates and selling dates to country recorder document dates. When analyzing pricing and price trends, I've been involved with professors from the UCB to accurately price real estate. If this problem isn't corrected, it will throw a very big curve into my statistics since all date counts before Feb 28 will be accurate, and all that cross the barrier will not. However, since we're measuring days, I'll probably introduce a correction myself by using a counter to record dates. This seems like a vendor supplied patch will cure it all. Is this the real problem you're analyzing, or am I way off base? Matt Bovee <mbovee@eagle.cc.ukans.edu> wrote in article <325E9EC2.685A@eagle.cc.ukans.edu>... > Hi, > > [Note: I am trying to insure that my question reaches a wide database audience, and > so am using two different subject contents. This message is identical to the > previous one sent by me; if you've read that one already, my apologies - you can > skip this one] > > 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: > > Active Databases, > Knowledge Discovery and Data Mining, > Data Warehouses, > Deductive Databases, > Fuzzy Databases/Logic/Queries, > GIS, > Image Databases, > Knowledge-bases, > Online Databases, > OO Databases, and > Text & Document Databases. > > 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, > > Matt Bovee > University of Kansas > Lawrence, KS > mbovee@ukanvm.cc.ukans.edu > (or if the first address fails, try mbovee@ukans.edu or > mbovee@eagle.cc.ukans.edu) >