> Before 100 people jump to correct me, yes, time_t overflows after > Tuesday, January 19, 03:14:07 2038. Fixing this requires that time_t by > typedefed as a 64-bit quantity and then programs using it must be > recompiled. One would hope that the world can find something better > than POSIX, C, and Unix by 2038.
Ok, the worst thing about the year 2000 problem, is that so few people understand it, yet think they do! People panic about things that probably won't break (Linux and utilities), yet ignore things that are more likely to break (user applications and data). 1) There is no quick fix! Yes, for the 2038 problem, you can just change time_t. But that only changes those applications that have been recompiled. The Y2K problem has almost always been about stuff that hasn't been recompiled and needs scrutiny before recompiling. The 2038 problem may be simpler in that the scrutiny can be done more automatically, but it's still a bigger job than just redefining time_t. 2) The sort of thinking that something else will be in common use before the problem comes around is exactly what has caused the problem in the first place. 2038 is 40 years in the future, but we have Y2K problems now for systems and programs that are 20 or 30 years old. People underestimate the longevity of code; the "if it ain't broke, don't fix it" philosophy is standard procedure (especially on mainframes, which is where Y2K will rear its ugly head, not on unix or wintel machines). 3) Setting a computer's date to 12/31/1999 and running it a few days does not test anything useful. The defects that this test will find are relatively trivial. For this to be more useful, it needs to be the same environment as you use in production (ie, you don't want to test the OS and utilities, you want to test your customer billing system, your automatic ordering system, your file archival system, your interest calculations, etc). Y2K problems are *complex*, they are usually not isolated to a few lines of code, and may not manifest themselves in a testing situation (ie, you may need to be on a network talking to a remote database server before a certain bug rears its head, etc). The real fix is to scrutinize all code. 4) Y2K problems have *already* happened, and we haven't hit 1/1/2000 yet. 5) I'm really glad no one has said "Y2K compliant" yet. There are a lot of poeple that use that term the same way they use "ISO 9000 compliant", as if there were a Y2K bugs clearning house, standards body, or certification program... 6) If you want to know if your system is going to have Y2K problems, then examine your own data and applications. UNIX in general will have few problems, and probably no major problems; however applications running on top of UNIX *will* have these problems. Same with Windows. Find out what's critical on your system and examine those components; if you do customer billing, then research the product that you use. If you have transactions (ie, databases) with other computers, then examine them as well. If you use commercial products, try to get upgrades to them; if you have data for those products, upgrade your data as well (it makes no sense to get new binaries, then forget that you have dates stored as character fields). 7) Finally - make backups, keep written records of all transactions, train your employees how to cope if the systems go down, and so forth. Ie, prepare for the worst. (I can't believe how inept some companies are; I was at a computer store whose point of sale system went down, and it took them ages to figure out what to do manually, and resulted in 4 people staffing each register). -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
