07-03-2011, 12:28 PM
Submitted by
D.UDAY BHASKAR
[attachment=9676]
Introduction:
Sign out from yahoo messenger or Gmail talk. Open your System Date and Time Settings. Change the year to anything beyond 2038. You can try setting the year to 2040. Now try logging in to either of the messenger. It does not log in and gives you some error.Surprised?
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 failure ,phone system interrupts, 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 echoes of the 2038 problem are already starting to appear in date calculations for mortgages and vital statistics. One second later, on 19-January-2038 at 3:14:08 AM GMT, disaster strikes.
WHAT'S ACTUALLY Y2K38 PROBLEM?
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 modem 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 3 I 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 l-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.
Internal Time and Date Representation of UNIX based Operating systems:
January 1, 1970 at 12:00 AM Greenwich Mean Time. A time_t value of 0 would be 12:00:00 AM (exactly midnight) l-Jan-1970; a time_t value of 1 would be 12:00:01 AM (one second after midnight) l-Jan-1970, etc... Since one year lasts for a little over 31 536 000 seconds, the time_t representation of January I, 1971 is about 31 536 000, the time_t representation for January 1, 1972 is about 63 072 000 seconds. 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 remaining 31 bits are used to store the number itself. The highest number these 3 1 data bits can store works out to exactly 2 147 483 647. A time_t value of this exact number, 2147483647, represents January 19, 2038, at 7 seconds past 3:14AM 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
Data types are the problem creators:
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. 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 2147483647 and then incremented by 1, will become -2147483648. 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, l9-January-2038 will suddenly become 13-Decernber-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 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 failure might not even be detected by the program calling it, and more often than not this means the calling program will crash.
