Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Y2K (Year 2000) Personal Contingency Planning -- Ignore unavailable to you. Want to Upgrade?

To: Bill Wexler who wrote (397)	7/14/1998 1:29:00 AM
From: Jonathan Bird	Respond to of 888

Please, please tell me that you're putting me on. I wish I could. Unfortunately the SSA is the least of the nations problems. Jon Bird

To: Bill Wexler who wrote (397)	7/14/1998 2:28:00 AM
From: Investor-ex!	Respond to of 888

Hi Bill, The "core" database of the annuity systems that I've encountered have been written using CCYY for the year of birth from the outset. They had to because even a cursory examination of the data domain revealed there were at least some annuitants born in the 1800's with the bulk born in the 1900's. The SSA's systems would have properly tracked the date of birth of their clients from the day the system was put into production. In the SSA's case, circa 1935, all of the retirees were born in the 1800's but were retiring in the 1900's. I would venture a guess that most annuitizing and forecasting systems dealing with human time spans would be largely y2k compliant, at least in regard to tracking birth dates, setting target dates, and recording significant events. This is the case with the system I am currently enhancing right now. However, this is not to say that these same systems are consistent in handling dates in the more peripheral areas of the system or that all date arithmetic is consistently and correctly using four digit years. Systems beyond this domain would have a much lower Y2k confidence level. All I can do is speak from experience. I've done maintenance on some pretty old stuff, billing, purchasing, order entry, invoicing, etc. and have seen things that would flat-out fail when the clock rolls over. I've seen some fairly bizarre date calculations that improperly account for the century, or mishandle the century, that have never been tested for post-2000. I know they haven't been tested because, from reading the code, their calculations would plainly be wrong. I'm sure many programmers out there have seen similar situations. I know you're down on the y2k scam-stocks, and I agree, as a lot of them are selling pop-guns when howitzers are needed to clean this stuff up. However, I think other threaders are confused when you paint all of y2k as a hoax, when clearly all of y2k is NOT a hoax. If it were a hoax, the fortune 500, the US government, and businesses around the world must have lost their minds, spending hundreds of billions of dollars on the y2k "hoax" for naught. You must believe the "alarmism" aspect of y2k is a hoax, not y2k itself. If so, I can understand this, as the belief in y2k "problems" as well as the projections of those "problems" cover a wide range of outcomes from non-event (you) to end-of-the-world (a la Pat Robertson). Right now, I'm in neither camp and will likely stay that way, simply because I know there's bad code out there that won't get fixed, much less tested. However, I do hope that the bulk of the really critical stuff (and not just in the USA) will get looked at. Hopefully, de Jager and Yardeni make the appropriate amount of noise that it does.