Monday, January 26, 2015

Y2K Bug

The Y2K Bug

Really ?

Y2K. The Millennium bug.

Approaching December 31 1999, the whole world was in panic.

Picture: The Y2K Bug.
Picture: The Y2K Bug.
As a programmer, I knew it was possibly a bit exaggerated, almost a hoax, because except for a few old COBOL programs, probably not into production anymore.

I knew that planes wouldn't crash. I knew that elevator wouldn't get stuck between two levels. 

I was an IT consultant at the CN then, and I was asked to check out a few C programs. I reported that no problem were to be expected in those programs or with the relational databases used, because today memory is not expensive, and the trick of using on two digits to code a year is not used.

Overview

The Y2K Bug, sometimes known as the Millennium Bug or Year 2000 Problem, was a result of digital storage using two-digit abbreviations for years in their systems. In the 1990s, many people were concerned that the rollover between December 31st, 1999 and January 1st, 2000 would result in mass computer failure.

Year 2038 problem

The Year 2038 problem is an issue for computing and data storage situations in which time values are stored or calculated as a signed 32-bit integer, and this number is interpreted as the number of seconds since 00:00:00 UTC on 1 January 1970 ("the epoch"). Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038, a problem analogous to the "Y2K problem" (also known as the "Millennium Bug"), in which 2-digit values representing the number of years since 1900 could not encode the year 2000 or later. Most 32-bit Unix-like systems store and manipulate time in this "Unix time" format, so the year 2038 problem is sometimes referred to as the "Unix Millennium Bug" by association.

No comments:

Post a Comment