Y2K38

A SEMINAR REPORT

Submitted By

AMIT KUMAR
in partial fulfilment for the award of the degree of

BACHELOR OF TECHNOLOGY
in COMPUTER SCIENCE AND ENGINEERING SCHOOL OF ENGINEERING

COCHIN UNIVERSITY OF SCIENCE & TECHNOLOGY KOCHI-682022 SEPTEMBER 2010

Division of Computer Engineering School of Engineering Cochin University of Science & Technology
Kochi-682022
_____________________________________________________

CERTIFICATE
Certified that this is a bonafide record of the seminar work titled

Y2k38
Done by AMIT KUMAR

of VII semester Computer Science & Engineering in the year 2010 in partial fulfillment of the requirements for the award of Degree of Bachelor of Technology in Computer Science & Engineering of Cochin University of Science & Technology

Dr. David Peter S. Head of the Division

Ms. Revathy.R. Seminar Guide

Y2K38

ACKNOWLEDGEMENT

I express my sincere thanks to Dr. David Peter (Head of the Department, Computer Science and Engineering), Mr. Sudeep P.Eliydom (Staff incharge) and Miss Revathy R. , my seminar guide for their kind co-operation for presenting the seminar. I also extend my sincere thanks to all other members of the faculty of Computer Science and Engineering Department and my friends for their co-operation and encouragement.

AMIT KUMAR

Division of Computer Engineering

Y2K38

ABSTRACT

Y2K38 (The Year 2038 Problem) is a problem that is occurring in the year 2038. Just as Y2K problems arise from programs not allocating enough digits for representing the year, Y2K38 problems arise from programs not allocating enough bits to the internal year. Y2K38 not only affects the computers but also many electronic chips. And these chips are embedded into the control electronics to manage the products functionality. After 19-jan- 2038 in a 32-bit machine, its clock will overflow and return erroneous values such as 1jan-1970 or 13-dec-1901. As embedded systems are used in satellites, space probe computers, navigation systems, power plants, atom bombs, missile controllers and in many other fields. So after 9-jan2038 these systems will go abnormal.

Division of Computer Engineering

ii

Y2K38

TABLE OF CONTENTS 1. INTRODUCTION............................................................................................6 2. WHAT'S SO SPECIAL ABOUT 2038?...........................................................7 3.HOW THE TIME AND DATES ARE CALCULATED? ................................8 4.WHAT WILL THE TIME_T'S DO WHEN THIS HAPPENS? ..................... 11 5.WHAT IS THE IMPORTANCE OF TIME? ...................................................14 6.WHAT ABOUT MAKING TIME_T UNSIGNED.............................. 15 IN 32-BIT SOFTWARE? 7.WHAT ARE THE CONSEQUENCES?.........................................................16 8. WHAT ARE THE SOLUTIONS?...................................................................18 9. WILL FIXING YEAR 2000 BUGS HELP FIX YEAR 2038......................... 20 BUGS? 10. CONCLUSION..............................................................................................21 . REFERENCE

Division of Computer Engineering

iii

Y2K38

Division of Computer Engineering

iv

Y2K38

1. INTRODUCTION

January 19, 2038 will be a serious problem for many platforms, because these systems will "run out of time". Starting at GMT 03:14:07, Tuesday, January 19, 2038,it is fully expect to see lots of things breaking magnificently: satellites falling out of orbit, massive power outages, hospital life support system failures, phone system interruptions, bank problems, etc. That's because one second later, 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. Most programs written in the C programming language are relatively immune to the Y2K problem, but suffer instead from the Year 2038 problem. This problem arises because most C programs use a library of routines called the standard time library (time.h). This library establishes a standard 4-byte format for the storage of time values, and also provides a number of functions for converting, displaying and calculating time values. a signed 4-byte integer has a maximum value of 2,147,483,647, and this is where the Year 2038 problem comes from. The maximum value of time before it rolls over to a negative (and invalid) value is 2,147,483,647, which translates into 19-January-2038 at 3:14:08 AM GMT On this date, any C programs that use the standard time library will start to have problems with date calculations. Because of its high compactness it is the mainly used embedded software. So y2k38 not only affects the computers, but also many embedded systems. The year 2000 was just a dry run. In case you think we can sit on this issue for another 30 years before addressing it, consider that the temporal echos of the 2038 problem are already starting to appear in date calculations for mortgages and vital statistics. One second later, on 19January-2038 at 3:14:08 AM GMT, disaster strikes.

Division of Computer Engineering

Y2K38

The year 2038 problem (also known as Unix Millennium Bug, Y2K38 or Y2.038K by analogy to the Y2K problem) may cause some computer software to fail before or in the year 2038. The problem affects all software and systems that both store system time as a signed 32-bit integer, and interpret this number as the number of seconds since 00:00:00 UTC on Thursday, 1 January 1970.[1] The furthest time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January 2038. Times beyond this moment will "wrap around" and be stored internally as a negative number, which these systems will interpret as a date in 1901 rather than 2038. This will likely cause problems for users of these systems due to erroneous calculations Further, while most programs will only be affected in or very close to 2038, programs that work with future dates will begin to run into problems much sooner. For example, a program that works with dates 20 years in the future will have to be fixed no later than in 2018. Because most 32-bit Unix-like systems store and manipulate time in this format, it is usually called Unix time, and so the year 2038 problem is often referred to as the Unix Millennium Bug. However, any other non-Unix operating systems and software that store and manipulate time this way will be just as vulnerable.

Division of Computer Engineering

Y2K38 Early problem:

In May 2006, reports surfaced of an early manifestation of the Y2038 problem in the AOLserver software. The software was designed with a kludge to handle a database request that should "never" time out. Rather than specifically handling this special case, the initial design simply specified an arbitrary time-out date in the future. The default configuration for the server specified that the request should time out after one billion seconds. One billion seconds (approximately thirty-two years) after 9:27.28 pm on 12 May 2006 is beyond the 2038 cutoff date. Thus, after this time, the time-out calculation overflowed and returned a date that was actually in the past, causing the software to crash. When the problem was discovered, AOL's server managers had to edit the configuration file and set the time out to a lower value

Division of Computer Engineering

Y2K38

Y2K-PROBLEM
The Year 2000 problem (also known as the Y2K problem, the millennium bug, the Y2K bug, or simply Y2K) was a problem for both digital (computerrelated) and non-digital documentation and data storage situations which resulted from the practice of abbreviating a four-digit year to two digits. In computer programs, the practice of representing the year with two digits becomes problematic with logical error(s) arising upon "rollover" from x99 to x00. This has caused some date-related processing to operate incorrectly for dates and times on and after January 1, 2000 and on other critical dates which were billed "event horizons". Without corrective action, it was suggested that longworking systems would break down when the "...97, 98, 99, 00..." ascending numbering assumption suddenly became invalid. Companies and organizations worldwide checked, fixed, and upgraded their computer systems. While no globally significant computer failures occurred when the clocks rolled over into 2000, preparation for the Y2K problem had a significant effect on the computer industry. There were plenty of Y2K problems, and that none of the glitches caused major incidents is seen as vindication of the Y2K preparation. However, some questioned whether the absence of computer failures was the result of the preparation undertaken or whether the significance of the problem had been overstated. Many banks have responded to the Y2K problem by forcing full 4-digit year entries on check forms, which helps to prevent the error from occurring in accounting environments.

Division of Computer Engineering

Y2K38

Year 2010 problem

Some systems had problems once the year rolled over to 2010. This was dubbed by some in the media as the "Y2K+10" or "Y2.01k" problem.[12] The main source of problems was confusion between hexadecimal number encoding and Binary-coded decimal (BCD) encodings of numbers. Both hexadecimal and BCD encode the numbers 09 as 0x00x9. But BCD encodes the number 10 as 0x10, whereas hexadecimal encodes the number 10 as 0x0A; 0x10 interpreted as a hexadecimal encoding represents the number 16. For example, because the SMS protocol uses BCD for dates, some mobile phone software incorrectly reported dates of SMSes as 2016 instead of 2010.[citation needed] Among the affected systems were EFTPOS terminals,[13] specific mobile phones[14] and older Sony PlayStation 3 models (except the Slim).[15] Windows Mobile is the first reported software to get this glitch as it changes the sent date of any phone message sent after 1 January 2010 from the year "2010" to "2016".[16] The most important such glitch occurred in Germany, where upwards of 20 million bank cards became unusable, and with Citibank Belgium, whose digipass customer identification chips stopped working

Division of Computer Engineering

Y2K38 Programming Problem

The practice of using two-digit dates for convenience predates computers. The need for bit conservationIn the 1960s, computer memory and mass storage were scarce and expensive, and most data processing was done on punched cards which represented text data in 80-column records. Programming languages of the time, such as COBOL and RPG, processed numbers in their character 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 punched cards were converted to magnetic tape and then disk files and later to simple databases, 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 digits for every date field was significant in the 1960s. Since programs at that time were mostly short-lived 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 missing two digits of the year a significant problem. There were exceptions, of course. The first person known to publicly address this issue 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,

Division of Computer Engineering

Y2K38
inertia and complacency caused it to be mostly unresolved until the last few years of the decade. In 1989 Erik Naggum was instrumental in ensuring that Internet mail used four digit representations of years by including a strong recommendation to this effect in the Internet host requirements document

Division of Computer Engineering

Y2K38

Alan Greenspan, 1998

I'm one of the culprits who created this problem. I used to write those programs back in the 1960s and 1970s, and was proud of the fact that I was able to squeeze a few elements of space out of my program by not having to put a 19 before the year. Back then, it was very important. We used to spend a lot of time running through various mathematical exercises before we started to write our programs so that they could be very clearly delimited with respect to space and the use of capacity. It never entered our minds that those programs would have lasted for more than a few years. As a consequence, they are very poorly documented. If I were to go back and look at some of the programs I wrote 30 years ago, I would have one terribly difficult time working my way through step-by-step.

Division of Computer Engineering

Y2K38

2. WHAT'S SO SPECIAL ABOUT 2038?

Just as Y2K problems arise from programs not allocating enough digits to the year, Y2K38 problems arise from programs not allocating enough bits to internal time. time_t is a data type used by C and C++ programs to represent dates and times internally Most programs written in the C programming language are relatively immune to the Y2K problem, but suffer instead from the Year 2038 problem. This problem arises because most C programs use a library of routines called the standard time library (time.h). This library establishes a standard 4-byte format for the storage of time values, and also provides a number of functions for converting, displaying and calculating time values. It is the basis for the CTime and CTimeSpan classes in MFC.A modern 32-bit computer stores a "signed integer" data type, such as time_t, in 32 bits. The first of these bits is used for the positive/negative sign of the integer, while the remaining 31 bits are used to store the number itself. The highest number these 31 data bits can store works out to exactly 2 147 483 647. A time_t value of this exact number, 2 147 483 647, represents January 19, 2038, at 7 seconds past 3:14 AM Greenwich Mean Time. So, at 3:14:07 AM GMT on that fateful day, every time_t used in a 32-bit C or C++ program will reach its upper limit. After this date, 32-bit clocks will overflow and return erroneous values such as 1-jan-1970 or 13-dec-1901.as c++ is a powerful programming language it is not only used as computer software but it is also used in many electronic chips. Because of its high compactness it is the mainly used embedded software. Satellites, space probe computers, navigation systems, power plants, atom bombs, missile controllers and many other important fields contains embedded systems which uses these kinds of chips. So after 19-jan- 2038 these systems will go abnormal.

Division of Computer Engineering

Y2K38

3. HOW THE TIME AND DATES ARE CALCULATED?

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) 1Jan-1970, a time_t value of 1 would be 12:00:01 AM (one second after midnight) 1-Jan-1970, etc... Since one year lasts for a little over 31 536 000 seconds, the time_t representation of January 1, 1971 is about 31 536 000, the time_t representation for January 1, 1972 is about 63 072 000 seconds.

Some example times and their exact time_t representations:

Date & time 1-Jan-1970, 12:00:00 AM GMT 1-Jan-1970, 12:00:01 AM GMT 1-Jan-1970, 12:01:00 AM GMT 1-Jan-1970, 01:00:00 AM GMT 2-Jan-1970, 12:00:00 AM GMT 3-Jan-1970, 12:00:00 AM GMT 1-Feb-1970, 12:00:00 AM GMT 1-Mar-1970,12:00:00 AM GMT 1-Jan-1971, 12:00:00 AM GMT 1-Jan-1972, 12:00:00 AM GMT 1-Jan-2003, 12:00:00 AM GMT 1-Jan-2038, 12:00:00 AM GMT 19-Jan-2038,03:14:07AM GMT 0 1 60 3 600 86 400 172 800 2 678 400 5 097 600 31 536 000 63 072 000 1 041 379 200 2 145 916 800 2 147 483 647 time_t representation

Division of Computer Engineering

10

Y2K38

By the year 2038, the time_t representation for the current time will be over 2140000000. And that's the problem. A modern 32-bit computer stores a "signed integer" data type, such as time_t, in 32 bits. The first of these bits is used for the positive/negative sign of the integer, while the remaining 31 bits are used to store the number itself. The highest number these 31 data bits can store works out to exactly 2 147 483 647. A time_t value of this exact number, 2 147 483 647, represents January 19, 2038, at 7 seconds past 3:14 AM Greenwich Mean Time. So, at 3:14:07 AM GMT on that fateful day, every time_t used in a 32-bit C or C++ program will reach its upper limit. One second later, on 19-January-2038 at 3:14:08 AM GMT, disaster strikes.

The following C program demonstrates this effect. It is strict ANSI C so it should compile on all systems that support an ANSI C compiler...
#include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <time.h> int main (int argc, char **argv) { time_t t; t = (time_t) 1000000000; printf ("%d, %s", (int) t, asctime (gmtime (&t))); t = (time_t) (0x7FFFFFFF); printf ("%d, %s", (int) t, asctime (gmtime (&t))); t++; printf ("%d, %s", (int) t, asctime (gmtime (&t)));

Division of Computer Engineering

11

Y2K38
return 0; }

The program produces the output:

1000000000, Sun Sep 9 01:46:40 2001 2147483647, Tue Jan 19 03:14:07 2038 -2147483648, Fri Dec 13 20:45:52 1901

Division of Computer Engineering

12

Y2K38

4. WHAT WILL THE TIME_T'S DO WHEN THIS HAPPENS?

Signed integers stored in a computer don't behave exactly like an automobile's odometer. When a 5-digit odometer reaches 99 999 miles, and then the driver goes one extra mile, the digits all "turn over" to 00000. But when a signed integer reaches its maximum value and then gets incremented, it wraps around to its lowest possible negative value. (The reasons for this have to do with a binary notation called "two's complement"; I won't bore you with the details here.) This means a 32-bit signed integer, such as a time_t, set to its maximum value of 2 147 483 647 and then incremented by 1, will become -2 147 483 648. Note that "-" sign at the beginning of this large number. A time_t value of -2 147 483 648 would represent December 13, 1901 at 8:45:52 PM GMT. So, if all goes normally, 19-January-2038 will suddenly become 13December-1901 in every time_t across the globe, and every date calculation based on this figure will go haywire. And it gets worse. Most of the support functions that use the time_t data type cannot handle negative time_t values at all. They simply fail and return an error code. Now, most "good" C and C++ programmers know that they are supposed to write their programs in such a way that each function call is checked for an error return, so that the program will still behave nicely even when things don't go as planned. But all too often, the simple, basic, everyday functions they call will "almost never" return an error code, so an error condition simply isn't checked for. It would be too tedious to check everywhere; and besides, the extremely rare conditions that result in the function's failure would "hardly ever" happen in the real world. (Programmers: when was the last time you checked the return value from printf( ) or malloc()?) When one of the time_t support functions fails, the

Division of Computer Engineering

13

Y2K38
failure might not even be detected by the program calling it, and more often than not this means the calling program will crash. . # Set the Time Zone to GMT (Greenwich Mean Time) for date calculations. for ($clock = 2147483641; $clock < 2147483651; $clock++)

print ctime($clock); Possibility 1: Tue Jan 19 03:14:01 2038 Tue Jan 19 03:14:02 2038 Tue Jan 19 03:14:03 2038 Tue Jan 19 03:14:04 2038 Tue Jan 19 03:14:05 2038 Tue Jan 19 03:14:06 2038 Tue Jan 19 03:14:07 2038 Fri Dec 13 20:45:52 1901 Fri Dec 13 20:45:52 1901 Fri Dec 13 20:45:52 1901 Possibility 2: Tue Jan 19 03:14:01 2038 Tue Jan 19 03:14:02 2038 Tue Jan 19 03:14:03 2038 Tue Jan 19 03:14:04 2038 Tue Jan 19 03:14:05 2038 Tue Jan 19 03:14:06 2038 Tue Jan 19 03:14:07 2038 Tue Jan 19 03:14:07 2038

Division of Computer Engineering

14

Y2K38
Tue Jan 19 03:14:07 2038 Tue Jan 19 03:14:07 2038 Possibility 3: Mon Jan 18 22:14:01 2038 Mon Jan 18 22:14:02 2038 Mon Jan 18 22:14:03 2038 Mon Jan 18 22:14:04 2038 Mon Jan 18 22:14:05 2038 Mon Jan 18 22:14:06 2038 Mon Jan 18 22:14:07 2038 Mon Jan 1 12:00:00 1970 Mon Jan 1 12:00:01 1970 The output of this script on Windows 2000 Professional Mon Jan 18 22:14:01 2038 Mon Jan 18 22:14:02 2038 Mon Jan 18 22:14:03 2038 Mon Jan 18 22:14:04 2038 Mon Jan 18 22:14:05 2038 Mon Jan 18 22:14:06 2038 Mon Jan 18 22:14:07 2038 Bad craziness! The script doesn't print 10 lines of output, there's simply no date output after 7 seconds

Division of Computer Engineering

15

Y2K38

5. WHAT IS THE IMPORTANCE OF TIME?

There is one major aspect of the physical world over which we have no control; namely TIME. Since this is true, time is usually considered to be the independent variable in most computer applications, and all other variable quantities are studied and measured with respect to it. Some familiar examples of physical phenomena that are measured with respect to time are velocity, acceleration, and frequency. If we desire to use a computer to control some quantity that varies with time, the computer must produce output control signals that also vary in accordance with the time scale of the physical world. This is called real time applications. In order to illustrate this concept, let us consider the case of a navigational control computer. Within the computer, calculation of distance traveled and present position depends upon instantaneous values of velocity and direction. Both of these are time varying quantities in the external, real physical world. Any corrections in speed or azimuth that are made by the computer in order to compensate for drift must be made on a real time basis. Previously for convenience when solving problems with computers, liberal use was made of time-scale factors. The applications of the real-time computation are almost unlimited in number. Some of these applications, such as gun fire control, automatic navigation, missile guidance, and machine control etc..With the advent of the space age, the utilization of real time computers for aiding navigation in outer space has become essential, since a human pilot could not possibly solve the complex problems of guidance and control in time to make the appropriate trajectory corrections. Speeded-up hybrid techniques can be applied directly to the problems of real-time computation and control. The ever-increasing demand for faster aircraft and

Division of Computer Engineering

16

Y2K38
missiles has placed such stringent requirements upon the computers and techniques in use today.

6. WHAT ABOUT MAKING TIME_T UNSIGNED IN 32-BIT SOFTWARE?

One of the quick-fixes that have been suggested for existing 32bit software is to re-define time_t as an unsigned integer instead of a signed integer. An unsigned integer doesn't have to waste one of its bits to store the plus/minus signed for the number it represents. This doubles the range of numbers it can store. Whereas a signed 32 -bit integer can only go up to 21 47 483 647, an unsigned32-bit integer can go all the way up to 4 294 967 295. A time_t of this magnitude could represent any date and time from 12:00:00 AM 1-Jan-1970 all the out to 6:23:15 AM 7-Feb-2106. Surely giving us more than enough year for 64-bit software to dominate the planate. It sounds like a good idea at first most of the stand ard time_t handling function do not accept negative time_t value any way. If we make time_t in to a data type that only represents posite number? Well there is problem. Time_t is not just use to store just dates and times, it is also used in many application to store difference between time/date values thai is , to answer the questionof how much time is there in between date A and date B? In these cas e, we do need time_t to negative values. It is entirely possible that date B comes before date A. Blindly changing time_t to an unsigned integer make the code useless. Changing time_t to an unsigned integer would means you dis fix one set of bug means year 2038 problem only introduce a new whole new set(time difference not being computed properly).

Division of Computer Engineering

17

Y2K38

7. WHAT ARE THE CONSEQUENCES?

The greatest danger with the Year 2038 Problem is its invisibility. The more-famous Year 2000 is a big, round number; it only takes a few seconds of thought, even for a computer-illiterate person, to imagine what might happen when 1999 turns into 2000. But January 19, 2038 is not nearly as obvious. Software companies will probably not think of trying out a Year 2038 scenario before doomsday strikes. Of course, there will be some warning ahead of time. Scheduling software, billing programs, personal reminder calendars, and other such pieces of code that set dates in the near future will fail as soon as one of their target dates exceeds 19-Jan-2038, assuming a time_t is used to store them. There are a large number of machines, platforms, and applications which could be affected by the 2038 problem. Most of these will (hopefully) be decommissioned before the critical date. However, it is possible that some machines going into service now, or legacy systems which have never been upgrades due to budget constrains, may still be operating in 2038. These may include process control computers, space probe computers, embedded systems in traffic light controllers, navigation systems, etc. It may not be possible to upgrade many of these systems. Hardware, such as clock circuits, which has adopted this time convention, may also be affected if 32-bit registers are used. While 32-bit CPUs may be obsolete in desktop computers and servers by 2038, they may still exist in microcontrollers and embedded circuits. For instance, the Z80 processor is still available as an embedded function within Altera programmable devices. Such embedded functions present a serious maintenance problem for all rollover issues like the year 2038 problem, since the package part number and other markings usually give no indication of the device's internal function. And don't forget emulators that allow older code (both applications and operating systems) to run on newer platforms. The C programming language is a popular and widely used programming language for creating computer programs. Programmers around

Division of Computer Engineering

18

Y2K38
the world embrace C because it gives maximum control and efficiency to the programmer. It is able to read and write code for a large number of platforms -everything from microcontrollers to the most advanced scientific systems can be written in C, and many modern operating systems are written in C. So all these things which utilizes time related function in C will go wrong. The 2038 problem is more likely to result in air traffic control disasters, life-support systems failure, and power grid meltdown than the Y2K problem. The Y2K problem is more likely to disrupt inventory control, credit card payments, pension plans, and the like. The 2038 problem may well be quite serious because it involves the basic system timekeeping functions from which most other time and date information is derived, whereas the Y2K problem more often involves higher-level application programs. Databases using 32-bit Unix time may survive through 2038, and care will have to be taken in these cases to avoid rollover issues.

Division of Computer Engineering

19

Y2K38

8. WHAT ARE THE SOLUTIONS?

Admittedly, some of my colleagues don't feel that this impending disaster will strike too many people. They reason that, by the time 2038 rolls around, most programs will be running on 64-bit or even 128-bit computers. In a 64-bit program, a time_t could represent any date and time in the future out to 292 000 000 000 A.D., which is about 20 times the currently estimated age of the universe. The problem with this kind of optimism is the same root problem behind most of the Year 2000 concerns that plagued the software industry in previous years: Legacy Code. Developing a new piece of software is an expensive and time-consuming process. It's much easier to take an existing program that we know works, and code one or two new features into it, than it is to throw the earlier program out and write a new one from scratch. This process of enhancing and maintaining "legacy" source code can go on for years, or even decades. The MS-DOS layer still at the heart of Microsoft's Windows 98 and Windows ME was first written in 1981, and even it was a quick "port" (without many changes) of an earlier operating system called CP/M, which was written in the 1970s. Much of the financial software hit by the various Year 2000 bugs had also been used and maintained since the 1970s, when the year 2000 was still thought of as more of a science fiction movie title than an actual impending future. Surely, if this software had been written in the 1990s its Year 2000 Compliance would have been crucial to its authors, and it would have been designed with the year 2000 in mind. But it wasn't. I should also mention that computer designers can no longer afford to make a "clean break" with the computer architectures of the past. No one wants to buy a new kind of PC if it doesn't run all their old PC's programs. So, just as the new generation of Microsoft Windows operating systems has to be able to run the old 16-bit programs written for Windows 3 or MS-DOS, so any new PC

Division of Computer Engineering

20

Y2K38
architecture will have to be able to run existing 32-bit programs in some kind of "backward compatibility" mode. Even if every PC in the year 2038 has a 64-bit CPU, there will be a lot of older 32-bit programs running on them. And the larger, more complex, and more important any program is, the better are its chances that that it'll be one of these old 32-bit programs. Upgrading a 32-bit machine it into 64-bit machine is very very expensive. Well-written programs can simply be recompiled with a new version of the library that uses, for example, 8-byte values for the storage format. This is possible because the library encapsulates the whole time activity with its own time types and functions. But unfortunately It is very difficult to find out these chips, because no one could exactly predict where these chips are exactly used .most of the people who designed these embedded systems were passed away .this make y2k38 a serious threat. Even if we find out these chips it is impractical to remove these chips from satellites and many other space equipments.

Division of Computer Engineering

21

Y2K38

System Solutions

There is no straightforward and general fix for this problem for existing CPU and operating system combinations, existing file systems, or existing binary data formats. Changing the definition of time_t data type to a 64-bit type would break binary compatibility for software, data storage, and may affect any code that deals with the binary representation of time. Changing time_t to an unsigned 32-bit integer, effectively allowing timestamps to be accurate until the year 2106, would affect programs that deal with time differences or dates before 1970, and thus would also break binary compatibility in many cases. Most operating systems for 64-bit architectures already use 64-bit integers in their time_t, and these operating systems are becoming more common, particularly in desktop and server environments. Using a (signed) 64-bit value introduces a new wraparound date that is over twenty times greater than the present age of the universe: approximately 292 billion years from now, on Sunday, 4 December 292,277,026,596 AD.[2] As of 2007, however, hundreds of millions of 32-bit systems are deployed, many in embedded systems, and it is far from certain that they will all be replaced by 2038. Additionally, 32-bit applications running on 64bit systems are likely to be affected by the issue. Despite the modern eighteen-to-twenty-four-month generational update in computer systems technology, embedded computers may operate unchanged for the life of the system they control. The use of 32-bit time_t has also been encoded into some file formats, which means it can live on for a long time beyond the life of the machines for which such file formats were originally designed. Alternative proposals have been made (some of which are in use) including storing either milliseconds or microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed-64 bit integer, providing a minimum of 300,000 years range.[5][6] Other proposals for new time representations provide

Division of Computer Engineering

22

Y2K38
different precisions, ranges, and sizes (almost always wider than 32 bits), as well as solving other related problems, such as the handling of leap seconds.

Division of Computer Engineering

23

Y2K38

9. WILL FIXING YEAR 2000 BUGS HELP FIX YEAR 2038 BUGS?
No, time_t is never, ever at fault in any Year 2000 bug. Year 2000 bugs usually involve one of three things: The user interface, i.e., what year do you assume if the user types in "00"; a database where only the last two digits are stored, i.e., what year do you assume if the database entry contains a 00 for its year; and, in rare instances, the use of data items (such as the struct tm data structure's tm_year member in a C or C++ program) which store the number of years since 1900 and can result in displays like "19100" for the year 2000. Year 2038 bugs, on the other hand, occur when a program reads in a date and carries it around from one part of itself to another. You see, time_t is a convenient way to handle dates and times inside a C or C++ program. For example, suppose a program reads in two dates, date A and date B, and wants to know which date comes later. A program storing these dates as days, months, and years would first have to compare the years, then compare the months if the years were the same, then compare the days if the months were the same, for a total of 3 comparison operations. A program using time_t's would only have to compare the two time_t values against each other, for a total of 1 comparison operation. Additionally, adding one day to a date is much easier with a time_t than having to add 1 to the day, then see if that puts you past the end of the month, then increase the month and set the day back to 01 if so, then see if that puts you past the end of the year, etc. If dates are manipulated often, the advantage of using time_t's quickly becomes obvious. Only after the program is done manipulating its time_t dates, and wants to display them to the user or store them in a database, will they have to be converted back into days, months, and years. So, even if you were to fix every Year 2000 Bug in a program in such a way that users and databases could use years as large as9999, it wouldn't even brush on any of the Year 2038 Bugs lurking within the same program.

Division of Computer Engineering

24

Y2K38

10. CONCLUSION
Still there is 34 years ahead; scientists are not thinking it as a big period. They are trying their best to find out a solution for Y2K38. Now looking back on all that has happened, I hope humanity has learned a valuable lesson with Y2K. The possible effects of Y2K had been known over 20 years ago!! Why did we wait so long to fix it? The answer is simple, we didnt think that the computers would last that long. Well, now that we know, we had better get going on the fix for Y2K38, the next computing doomsday. Weve got 34 years and a few days to fix it, so lets get it done now! Of course, Im being idealistic we wont begin to worry about Y2K38 until there are only a few years left before it arrives. I really cant wait for that!! Can you? Good luck and I hope no ones flying car breaks down in 2038! : -

Division of Computer Engineering

25

Y2K38

11. REFERENCE

www.google.com http://www.sitepoint.com/blogs/2010/08/24/is-your-php-application-affectedby-the-y2k38-bug/ http://computer.howstuffworks.com/ http://en.wikipedia.org/wiki/Year_2038_problem http://maul.deepsky.com/~merovech/2038.html#What_operating_systems_and _platforms_are_affected_by_it

Division of Computer Engineering

26