4 ms·

Maybe it's because of how young I was at the time, but I remember media outlets reporting on the Y2K problem, and showing video of hundreds of older computing d

Maybe it's because of how young I was at the time, but I remember media outlets reporting on the Y2K problem, and showing video of hundreds of older computing devices that were being retired (thrown in landfills) because they wouldn't work properly after the date change happened. Maybe this isn't a "real" failure, and the symptom of some IT departments working diligently to solve the problem before it happened. In any case though, I'm curious how inaccurate the televised reality from my youth actually was.

rovr138 9y ago
Y2K was a software issue. In short and very simple terms, some software stored date as DD/MM/YY. It would asume that for year it would always prefix 19. The problem was when you reached /00. Any calculations or software decisions that happened based on that date, it would be off. Way off. Some solutions where expanding the date to YYYY or adding a prefix to the new dates. Dates without the prefix would be 19xx. Date with the prefix X was 19xx and dates with prefix Y where 20xx.
- vizeroth 9y ago
  Another solution was to set the prefix for 2-digit years on a sliding scale, so they are interpreted as a date within a specific 100-year period (date windowing). For example, see the 2029 rule: https://support.microsoft.com/en-us/help/214391/how-excel-works-with-two-digit-year-numbers https://support.microsoft.com/en-us/help/214391/how-excel-wo... This turned out to be one of the most cost-effective methods of fixing the problem, and was probably one of the most likely to be implemented. This was especially the case in situations involving software which ran closer to the hardware (for example, BIOS or firmware) or on systems where RAM or storage couldn't be increased and/or the change might increase the software's requirements beyond the system's capabilities. 32-bit Unix timestamps have the 2038 problem. Despite how common these problems have been in the history of computers, we keep making them: https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs https://en.wikipedia.org/wiki/Time_formatting_and_storage_bu...
- rabboRubble 9y ago
  There were a couple of computers in my shop that had a Y2K BIOS issue. Although there is a sort of software in the form of firmware on BIOS, many people considered this sort of Y2k error presentation a hardware problem. So, while a Y2K compliance program dealt mostly with software, a complete program went through and tested all hardware in inventory.
- jlebrech 9y ago
  the issue was a closed source problem, you could easily add the option to switch between 19 and 20 for calculations. or have a pre 2000 instance of the app and a post 2000.
asveikau 9y ago
The problem was that media reports at the time seemed to assume that anything with a computer would completely blow up, instead of rationally thinking through much more benign consequences of a date or calendar being wrong. The image of a bunch of perfectly capable computers being discarded for no reason describes this media frenzy wonderfully.

rovr138 9y ago

Y2K was a software issue. In short and very simple terms, some software stored date as DD/MM/YY. It would asume that for year it would always prefix 19. The problem was when you reached /00. Any calculations or software decisions that happened based on that date, it would be off. Way off. Some solutions where expanding the date to YYYY or adding a prefix to the new dates. Dates without the prefix would be 19xx. Date with the prefix X was 19xx and dates with prefix Y where 20xx.

vizeroth 9y ago
Another solution was to set the prefix for 2-digit years on a sliding scale, so they are interpreted as a date within a specific 100-year period (date windowing). For example, see the 2029 rule: https://support.microsoft.com/en-us/help/214391/how-excel-works-with-two-digit-year-numbers https://support.microsoft.com/en-us/help/214391/how-excel-wo... This turned out to be one of the most cost-effective methods of fixing the problem, and was probably one of the most likely to be implemented. This was especially the case in situations involving software which ran closer to the hardware (for example, BIOS or firmware) or on systems where RAM or storage couldn't be increased and/or the change might increase the software's requirements beyond the system's capabilities. 32-bit Unix timestamps have the 2038 problem. Despite how common these problems have been in the history of computers, we keep making them: https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs https://en.wikipedia.org/wiki/Time_formatting_and_storage_bu...
rabboRubble 9y ago
There were a couple of computers in my shop that had a Y2K BIOS issue. Although there is a sort of software in the form of firmware on BIOS, many people considered this sort of Y2k error presentation a hardware problem. So, while a Y2K compliance program dealt mostly with software, a complete program went through and tested all hardware in inventory.
jlebrech 9y ago
the issue was a closed source problem, you could easily add the option to switch between 19 and 20 for calculations. or have a pre 2000 instance of the app and a post 2000.

asveikau 9y ago

The problem was that media reports at the time seemed to assume that anything with a computer would completely blow up, instead of rationally thinking through much more benign consequences of a date or calendar being wrong. The image of a bunch of perfectly capable computers being discarded for no reason describes this media frenzy wonderfully.