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

Dave Wotton <Dave.Wotton@it.camcnty.gov.uk> wrote: >tom.kustner@emjay.com (Tom Kustner) wrote: >> >>The year 2000 *is* a leap year. >> >>If you still have doubts, go to >>http://www.year2000.com/y2karchive.html and check the FAQ. >> >>Tom Kustner >> >> >This is just the last of a long line of "oh-yes-it-is, oh-no-it-isn't" >sort of argument. >It's irrelevant. Two things, folks: 1. Tom Kustner is correct. The Julian calendar had a simple rule: Years divisible by 4 are leap years. As centuries passed, astronomers noticed an increasing discrepancy between the calendar and observed astronomical events. The issue was finally resolved when Pope Gregory in the 16th century decreed this additional rule: All years ending in '00' are NOT leap years, EXCEPT when it is divisible by 400. Thus, 1600, 2000, 2400, etc. are leap years. The last "skipped" leap year was 1900, and the next will be 2100. This gives the Gregorian calendar a 400 year cycle, and years average out to 365.2425 days. I don't know how close this jives with current measurements of Earth's orbit, but it's still the calendar in use today. 2. Dave Wotton is correct. The argument about leap years is irrelevant. The Year 2000 'bug' is not about leap years. It's primarily about legacy systems--old programs still in use today, typically written in COBOL--that use 2 digits to store the year. Back when disk and tape densities were low and disk storage costs were high, you did whatever you could to save on storage space. Using 4 digits to store a year was considered wasteful. If you have a master file with 1 million records, every byte saved in your record layout translates into roughly 1 MB of saved disk space. When your storage space is measured in megabytes--not gigabytes--that's a significant savings. And that's assuming you even have the room to store the master file on disk, instead of on a series of 9-track (or the even older 7-track) tapes. Scrimping on storage space wherever possible (packed decimal, binary, bit fiddling, program overlays) was still taught as the proper technique when I was in college in the 1970's. In an Assembler course, my grade on one program was reduced because I used an 'add' instruction when I could have used an 'add half', and saved 2 bytes. Functionally, it made no difference which instruction I used. In COBOL, the big new thing was 'structured programming', meaning writing your COBOL program without using GOTO's--something older programmers I ran into later couldn't understand. Pascal didn't exist yet, C was a letter of the alphabet, and no one ever heard of objects, or Bill Gates for that matter. I wrote a COBOL application back then for the Georgia Library Association that used 2-digit years. Using a typical technique for saving space, an entry of '00' signified a life member. No thoughts about the year 2000. In current databases, the date field will handle a wide range of dates. In Oracle, the date field range is from January 1, 4712BC to December 31, 4712AD. Other databases have similar ranges. However, this has not stopped enterprising programmers from defeating the built-in safety net. We have a DB2 application in use today where the programmers--probably from old habit--used NUMBER(2) fields instead of DATE to define years. The clock is ticking. Here's a trick to try with your PC. Set the date to December 31, 1999 at 23:58. Turn off the power and wait about 5 minutes. Turn the PC back on and display the date and time. In older PC's, the date will revert back to 1980. Chances are, by the time 1999 rolls around, most businesses will have replaced all their old PC's. But what about all the schools? --- Bolen Coogler DBA, BellSouth Information Systems