I'm a programmer with many old software programs (legacy systems) I have to support. I have no idea what you mean by "a bomb" (sounds spooky), however...
None of my applications are going to shut down the power grid or crash the US telecommunications system, but the date calculations they use prevent the applications from working properly.
In fact, the last support call I had was ironic. Our company has decided to back-date the computers (to 1972) to avoid the Y2K problems in the operating system (the year 1972 has the same calendar "footprint" as the year 2000, (with Jan 1 being a Saturday, the 2nd a Sunday, same pattern of leap years, etc.) -- however the software I wrote was "Y2K compliant" and assumed any 2-digit year less than 80 was in the next century (this is referred to as a "pivot year" algorithm for handling 2-digit year entries). My Y2K compliant software WILL NOT RUN properly on a computer back-dated to 1972 to address a Y2K problem in the operating system.
This is a catch-22 situation -- and our company has a real problem on it's hands (this is prior to the PC platfom and we no longer OWN a system to develop software with). If my experience is any indication, a lot of systems will have Y2K-related problems that will not be solved completely.
I wish that you were correct in your claim that Y2K is "a load of shit", however my own experience would suggest a more prudent (and thoughtful) view of this issue.
Slashdot Mirror
I'm a programmer with many old software programs (legacy systems) I have to support. I have no idea what you mean by "a bomb" (sounds spooky), however...
None of my applications are going to shut down the power grid or crash the US telecommunications system, but the date calculations they use prevent the applications from working properly.
In fact, the last support call I had was ironic. Our company has decided to back-date the computers (to 1972) to avoid the Y2K problems in the operating system (the year 1972 has the same calendar "footprint" as the year 2000, (with Jan 1 being a Saturday, the 2nd a Sunday, same pattern of leap years, etc.) -- however the software I wrote was "Y2K compliant" and assumed any 2-digit year less than 80 was in the next century (this is referred to as a "pivot year" algorithm for handling 2-digit year entries). My Y2K compliant software WILL NOT RUN properly on a computer back-dated to 1972 to address a Y2K problem in the operating system.
This is a catch-22 situation -- and our company has a real problem on it's hands (this is prior to the PC platfom and we no longer OWN a system to develop software with). If my experience is any indication, a lot of systems will have Y2K-related problems that will not be solved completely.
I wish that you were correct in your claim that Y2K is "a load of shit", however my own experience would suggest a more prudent (and thoughtful) view of this issue.