Presented by:
Suprabhat A
Vamsi Krishna D

---

[attachment=10280]
Abstract
We have seen at the starting of this millennium how software’s have been affected by a bug called Y2K bug normally termed as Y2K problem. We were succeed in resolving that problem .If we think now there is no other bug which can effect any software or application which is being used by us then we are mistaken .A bug is again going to affect all software’s and application which is being used by us. This bug is 2K38 bug termed as 2K38 problems which are going to affect software’s. “Year 2038” is frequently abbreviated to "Y2038" or sometimes "Y2K38".So, we have to be prepared in advance so that this bug will not show its affect on software’s by taking predictions. The year 2038 problem may cause some computer software to fail before or in the year 2038. This paper deals with cause of The 2038 BUG, effects of 2K38 problem and solution to 2K38 problem
1. Introduction to Y2K problem:
Y2K was the common abbreviation for the Year 2000 Problem. The abbreviation combines the letter Y for "year", and k for the Greek prefix kilo meaning 1000; hence, 2K signifies 2000. It also named the Millennium Bug because it was associated with a roll-over of the millennium. The Year 2000 problem (also known as the Y2K problem, the millennium bug, and the Y2K Bug) was the result of a practice in early computer program design that caused some date-related processing to operate incorrectly for dates and times on and after January 1, 2000. It engendered widespread concern that critical industries (such as electricity or financial) and government functions would cease operating at exactly midnight, January 1, 2000, and on other critical dates which were billed as "event horizons". This fear was fueled by the attendant press coverage and other media speculation, as well as corporate and government reports. Companies and organizations world-wide checked and upgraded their computer systems. The preparation for Y2K thus had a significant effect on the computer industry. No significant computer failures occurred when the clocks rolled over into 2000. Debate continues on whether the absence of computer failures was the result of the preparation undertaken or whether the significance of the problem had been overstated. The first recorded mention of the Year 2000 Problem was on a Usenet Newsgroup on Saturday, January 19, 1985 by Usenet poster, Spencer Bolles. It was speculated that computer programs could stop working or produce erroneous results because they stored years with only two digits and that the year 2000 would be represented by 00 and would be interpreted by software as the year 1900. This would cause date comparisons to produce incorrect results. It was also thought that embedded systems, making use of similar date logic, might fail and cause utilities and other crucial infrastructure to fail.
2. Causes of Y2K problem:
The underlying programming problem was real, but more subtle than many realize. The practice of using two-digit dates for convenience long predates computers, notably in artwork. Abbreviated dates do not pose a problem for humans, as works and events pertaining to one century are sufficiently different from those of other centuries. Computers, however, are unable to make such distinctions.
In the 1960s, computer memory and storage were scarce and expensive, and most data processing was done on punch cards which represented text data in 80-column records. Programming languages of the time, such as COBOL and RPG, processed numbers in their ASCII or EBCDIC representations. They occasionally used an extra bit called a "zone punch" to save one character for a minus sign on a negative number, or compressed two digits into one byte in a form called binary-coded decimal, but otherwise processed numbers as straight text. Over time the punch cards were converted to magnetic tape and then disk files and later to simple databases like ISAM, but the structure of the programs usually changed very little. Popular software like dBase continued the practice of storing dates as text well into the 1980s and 1990s.
Saving two characters for every date field was significant in the 1960s. Since programs at that time were mostly short-lived affairs programmed to solve a specific problem, or control a specific hardware-setup, neither managers nor programmers of that time expected their programs to remain in use for many decades. The realization that databases were a new type of program with different characteristics had not yet come, and hence most did not consider fixing two digits of the year a significant problem. There were exceptions, of course; the first person known to publicly address the problem was Bob Bemer who had noticed it in 1958, as a result of work on genealogical software. He spent the next twenty years trying to make programmers, IBM, the US government and the ISO aware of the problem, with little result. This included the recommendation that the COBOL PICTURE clause should be used to specify four digit years for dates. This could have been done by programmers at any time from the initial release of the first COBOL compiler in 1961 onwards. However, lack of foresight, the desire to save storage space, and overall complacency prevented this advice from being followed. Despite magazine articles on the subject from 1970 onwards, the majority of programmers only started recognizing Y2K as a looming problem in the mid-1990s, but even then, inertia and complacency caused it to be mostly ignored until the last few years of the decade.
The cause of the Y2K problem is pretty simple. Computer programmers have been in the habit of using two digit placeholders for the year portion of the date in their software. For example, the expiration date for a typical insurance policy or credit card is stored in a computer file in MM/DD/YY format (e.g. - 08/31/99). Programmers have done this for a variety of reasons, including:

* That's how everyone does it in their normal lives. When you write a check by hand and you use the "slash" format for the date, you write it like that.
* It takes less space to store 2 digits instead of 4 (not a big deal now because hard disks are so cheap, but it was once a big deal on older machines).
* Standards agencies did not recommend a 4-digit date format until recently.
* No one expected a lot of this software to have such a long lifetime. People writing software in 1970 had no reason to believe the software would still be in use 30 years later.
3. Effects of Y2K problem.
The 2-digit year format creates a problem for most programs when "00" is entered for the year. The software does not know whether to interpret "00" as "1900" or "2000". Most programs therefore default to 1900. That is, the code that most programmer's wrote either prepends "19" to the front of the two-digit date, or it makes no assumption about the century and therefore, by default, it is "19". This wouldn't be a problem except that programs perform lots of calculations on dates. For example, to calculate how old you are a program will take today's date and subtract your birthdate from it. That subtraction works fine on two-digit year dates until today's date and your birthdate are in different centuries. Then the calculation no longer works. For example, if the program thinks that today's date is 1/1/00 and your birthday is 1/1/65, then it may calculate that you are -65 years old rather than 35 years old. As a result, date calculations give erroneous output and software crashes or produces the wrong results.
The important thing to recognize is that that's it. That is the whole Year 2000 problem. Many programmers used a 2-digit format for the year in their programs, and as a result their date calculations won't produce the right answers on 1/1/2000. There is nothing more to it than that.
Even before January 1, 2000 arrived, there were also some worries about September 9, 1999 (albeit lesser compared to those generated by Y2K). This date could also be written in the numeric format, 9/9/99. This date value was frequently used to specify an unknown date; it was thus possible that programs might act on the records containing unknown dates on that day. It is also somewhat similar to the end-of-file code, 9999, in old programming languages. It was feared that some programs might unexpectedly terminate on that date. The bug however was more likely to confuse computer operators rather than machines.
Another related problem for calculations involving the year 2000 was that it was a leap year even though years ending in "00" are normally not leap years. A year is a leap year if it is divisible by 4 but not divisible by 100 unless also divisible by 400. For example, 1600 was a leap year, but 1700, 1800 and 1900 were not. Fortunately most programs were fixed in time.
The problem was compounded by the need of many systems, especially in the financial services sector, to calculate expiry and renewal dates in the future. For example, a company that sold five-year bonds would start getting Y2K problems in 1995, when its systems needed to calculate an expiry date of 2000; with two-digit years, the "00" of the expiry date would appear to be earlier than the "95" of the start date.
• Before 2000
In 1999 HSBC issued 10,000 card swipe machines, manufactured by Racal, to retailers, but a Y2K flaw prevented them from reading expiration dates properly. The stores had to rely on paper transactions, as they do when there are power failures or phone line failures, until replacement machines arrived
• On 1 January 2000
When January 1, 2000 arrived there were problems generally regarded as minor. Problems did not always have to occur precisely at midnight. Some programs were not active at that moment, and would only show up when they were invoked. Not all problems recorded were directly linked to Y2K programming in a causal relationship; minor technology glitches occur on a regular basis, as anyone who ever had to reboot a personal computer will recognize.
Reported problems include:
• In Ishikawa, Japan radiation-monitoring equipment failed at midnight, but officials said there was no risk to the public.
• In Onagawa, Japan, an alarm sounded at a nuclear power plant at two minutes after midnight. In Japan, at two minutes past midnight, Osaka Media Port, a telecommunications carrier, found errors in the date management part of the company's network.
4. Solution of Y2K problem
The solution, obviously, is to fix the programs so that they work properly. There are a couple of standard solutions:
* Recode the software so that it understands that years like 00, 01, 02, etc. really mean 2000, 2001, 2002, etc.
* "Truly fix the problem" by using 4-digit placeholders for years and recoding all the software to deal with 4-digit dates
5. Introduction to 2K38 problem
"Year 2038" is frequently abbreviated to "Y2038" or sometimes "Y2K38" in software professionals' jargon.The year 2038 problem may cause some computer software to fail before or in the year 2038. The problem affects programs that use the POSIX time representation, which represents system time as the number of seconds since
January 1, 1970. This representation is standard in Unix-like operating systems and also affects software written for most other operating systems because of the broad deployment of C. On most 32-bit systems, the time_t data type used to store this second count is a signed 32-bit integer. The latest time that can be represented in this format, following the POSIX standard, is 03:14:07 UTC on Tuesday, January 19, 2038. Times beyond this moment will "wrap around" and be represented internally as a negative number, and cause programs to fail, since they will see these times not as being in 2038 but rather in 1970 or 1901, depending on the implementation. Erroneous calculations and decisions may therefore result.
Starting at GMT 03:14:07, Tuesday, January 19, 2038, It is expected to see lots of systems around the world breaking magnificently: satellites falling out of orbit, massive power outages (like the 2003 North American blackout), hospital life support system
failures, phone system interruptions, banking errors, etc. One second after this critical second, many of these systems will have wildly inaccurate date settings, producing all kinds of unpredictable consequences. In short, many of the dire predictions for the year 2000 are much more likely to actually occur in the year 2038! Consider the year 2000 just a dry run.
6. Causes of 2K38 problem
Time_t is a data type used by C and C++ programs to represent dates and times internally. (Windows programmers out there might also recognize it as the basis for the CTime and CTimeSpan classes in MFC.) time_t is actually just an integer, a whole number, that counts the number of seconds since January 1, 1970 at 12:00 AM
Greenwich Mean Time. A time_t value of 0 would be 12:00:00 AM (exactly midnight)
1-Jan-1970, a time_t value of 1 would be 12:00:01AM (one second after midnight)
1-Jan-1970, etc..
some example times and their exact time_t representations:
Date & time time_t representation
1-Jan-1970, 12:00:00 AM GMT 0
1-Jan-1970, 12:01:00 AM GMT 60
1-Jan-1970, 01:00:00 AM GMT 3 600
1-Jan-1971, 12:00:00 AM GMT 31 536 000
1-Jan-1972, 12:00:00 AM GMT 63 072 000
1-Jan-2038, 12:00:00 AM GMT 2 145 916 800
19-Jan-2038, 03:14:07 AM GMT 2 147 483 647