Y 2 K 38

Y2K38: Problems & Solutions
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. Thats
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. The year
2038 problem (also known as Unix Millennium Bug, Y2K38 orY2.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. The furthest
time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January2038. 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 than2038.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.
Department of Computer Science and Engineering, September 2011

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.
2. EARLY PROBLEMS
In May 2006, reports surfaced of an early manifestation of the Y2038 problem in the
AOL server 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 thirtytwo 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
2.1 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(computer related) and non-digital
documentation and data storage situations which resulted from the practice of abbreviating a fourdigit 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 long working 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.
2.2 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 as0x10, whereas hexadecimal encodes the number 10 as 0x0A; 0x10 interpreted as
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.
Among the affected systems were EFTPOS terminals, specific mobile phones and older Sony
PlayStation 3 models (except the Slim).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". The most important such glitch occurred in Germany, where upwards of20 million
bank cards became unusable, and with Citibank Belgium, whose digipass customer identification
chips stopped working
2.3 Programming Problem

The practice of using two-digit dates for convenience predates computers. The need
for bit conservation in 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 intone 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 clauses 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 in1961 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 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
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.
3 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 for present 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, in32 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 AMGMT 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.
4. 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 Meantime. 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:01 AM (one second after midnight) 1-Jan-1970, etc...
Since one year lasts for a little over 31 536000 seconds, the time_t
representation of January 1, 1971 is about 31536 000, the time_t representation
for January 1, 1972 is about 63 072000 seconds.
Some example times and their exact time_t representations:
Date & time time_t representation
1-Jan-1970, 12:00:00 AM GMT
1-Jan-1970, 12:00:01 AM GMT
1-Jan-1970, 12:01:00 AM GMT
60
1-Jan-1970, 01:00:00 AM GMT
3 600
2-Jan-1970, 12:00:00 AM GMT
86 400
3-Jan-1970, 12:00:00 AM GMT
172 800
1-Feb-1970, 12:00:00 AM GMT
2 678 400
1-Mar-1970, 12:00:00 AM GMT
5 097 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-2003, 12:00:00 AM GMT
1 041 379 200
1-Jan-2038, 12:00:00 AM GMT
2 145 916 800
19-Jan-2038, 03:14:07AM GMT
2 147 483 647
By the year 2038, the time_t representations 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);
t++;
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
5. 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 -2147 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 13-December-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 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
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
10

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
11
6 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
number. Some of
these
computation are almost unlimited in
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 realtime computation and control. The ever-increasing demand for faster aircraft and missiles has placed
such string requirements upon the computers and techniques in use today.
12
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 computerilliterate 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 constraints, 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 given 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. A programmer around the world embraces
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 utilize time related functions 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
13

involves the basic system time keeping 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-bitUnix time may survive through 2038, and care will have to be taken in these
cases to avoid rollover issues.
7.1 Vulnerable systems

Embedded systems are most likely to be affected by the 2038 bug. Transportation
systems from flight to automobiles increasingly use embedded systems. New airplanes contain
advanced avionics such as inertial guidance systems and GPS receivers that also have considerable
safety requirements. Another major use of embedded systems is in communications devices,
including cellphones and internet appliances (routers, wireless access points, etc) which rely on
storing an accurate time and date and are increasingly based on subsets of Unix (Android, Apple
IOS, light versions of Linux etc).
As of 2010, most of these systems use 8/16 bit processors, even as desktop systems
are transitioning to 64 bit systems. Despite the modern 1824-month generational update in
computer systems technology, embedded systems are designed to last the life of the machine they
are built into. It is easily conceivable that some may still be in use by 2038. It is impractical (or in
some cases impossible) to upgrade the software on these systems, so most will simply have to be
replaced at significant cost.
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.
7.2 Data structures with time problems

Many data structures in use today have 32 bit time representations embedded into their structure. A
full list of these data structures is impossible to derive but there are well known data structures that
have the UNIX time problem.
file systems (like many in ode file systems still in use)
data bases (that have 32 bit time fields)
COBOL databases from the 1970s, 1980s and 1990s that have not been replaced by 2038
compliant SQL systems
14
embedded factory, refinery control and monitoring subsystems
assorted medical devices
assorted military devices
Each one of these places where data structures using 32 bit time are in place have their own risks
related to failure of the product to perform as designed.
15
8 EXPERIMENTS
8.1 Experiment 1
Lets see some simple experiments that I did on my computer which runs in 32 bit Windows 7.
Step 1:
First I need a net based application to do the experiment. I took my Google talk (can also take yahoo
messenger also) and sign out from it.
Step 2:
Now I need to change my system time to a time above 2038. So I changed my system time to 31
July 2045 as shown in figure below.
Fig 1: Step 1
Fig 2: Step 2
Step 3:
Now I tried to login back to my Google talk. And
observed what I got.
There I got an error message as shown in fig 4
below. It says that Google talk encountered an
internal error and need to close it. But this leads to
another doubt. Now the system time of my PC and
Google Server will be different. Is this caused the
error? So I continued my experiment.
Step 4:
Now I changed my time to year between current
time and 2038. I changed my system time to 31
July 2031 and tried to sign in again. There I got a different error message
Connecting to google talk network has failed due to an expired authentication certificate. The
common cause of this expired certificate is due to time differences between your computer and the
Google talk network. Please verify your computer's clock settings are correct and then retry
It clearly says that its due to time difference between my pc and Google Talk server. And the
previous error report differs from this. So it shows that the Y2K38 bug will hit Google Network.
16
Fig 3: Step 3
Fig 4: Step 3 error report
17
8.2 Experiment 2
Now in this experiment I changed the platform. I took a laptop with a 64 bit Windows
7 and done the same steps 1 to 4 as I done on 32 bit computer. Interestingly I got the same result as
in the previous experiment and it is show below from fig 6 to 10.
These experiments show that even if the systems changed from 32 to 64 bit there will
be some problems still remaining. Google talk network doesnt support 64 bit date. It shows that we
need a lot of effort to overcome this problem.
18
Fig 6: Step 1
Fig 7: Step 2
19

Fig 8: Step 3
20

Fig 10 : Step 4
From all this experiments we can say that y2k38 bug will affect even the Google server!!!
21
9. 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
to292 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 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
lot of older 32-bit programs running on them. And the
22

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 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 much other space equipment
.
9.1 What about making time_t unsigned in 32-bit software?

One of the quick-fixes that have been suggested for existing 32-bit software is to redefine 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 years for 64-bit software to dominate the planet .It
sounds like a good idea at first most of the standard 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 positive number? Well
there is problem. Time_t is not just use to store just date sand times, it is also used in many
application to store difference between time/date values that is, to answer the question of how
much time is there in between date A and date B? In these cases, 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.
9.2 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
23

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 times tamps 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. 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 64- bit systems are likely to be affected by the issue. Despite the modern eighteen-totwenty-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. Other proposals for new time representations provide 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.
9.3 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
24

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 as 9999, it wouldn't even brush on any of the Year 2038 Bugs
lurking within the same program.
9.4 Is this a severe problem?

No, this is not going to being a severe problem, only if we
work a lot. We need to out date the 32 bit processors & time_t from this world
before the year 2038. But it will cause a great expense, probably of billions or
trillions. Many may think that why should we bother about it now. 64 bit
processors are arriving which will not be effected by this. A 64 bit CPU doesn't
mean y2038 cleans.
For example, your shiny new Apple computer has a 64 bit processor in it.
But the operating system is still operating with 32 bit integers and a 32 bit
25

time_t and has a 2038 bug. Why? When you change the integer size you need
to recompile all your software. Then Mac applications would have to ship 32 bit
and 64 bit versions. Apple has dealt with this sort of thing gracefully several
times in the past ("fat binaries" for the Motorola -> PowerPC switch, "universal
binaries" for the PowerPC -> Intel switch), but it's still a painful and buggy
process for both developer and user. (Note: OS X 10.6 appears to have made
the jump to 64 bit software).
And just because you're using a shiny new 64 bit processor doesn't mean
everyone else will. 32 bit processors will remain cheap and plentiful, not just in
PCs and old hardware, but in your car, your phone, your watch, youre TV, your
DVD player...
This problem will only become worse as time goes on, which is bad
because upgrades take a long time. Lets see what a programmer and
computer scientist, Paul Sheer from US told about this.
Even if all computers are 64-bit, many programs still convert the time to a 32bit integer. Some even encode the time as a 4-byte sequence and send it over
the network or put it in a database. So even some databases and network
protocols will have to be upgraded and tested. Even if the programs appear to
do the correct thing with the time, they will still have to be tested through
2038. This testing effort will be enormous and will cost software companies
billions or even trillions. Like Y2K, all devices will have to be tested. For most
devices testing will not be economically viable. So non-critical devices, not
under warranty need to be ignored. For most other devices and systems,
testing will reveal no problem. Finally, there will be a small number of systems
that require meticulous code audits and fixes. All the testing, and the fixes
required, will cost the industry "trillions" of dollars.
For those of you who think that "the year 200 bug never happened"
I'd like to remind you that a lot of money and effort was put into the Year 2000
problem during the three years before the end of the century. Many, many bugs
were uncovered and corrected (I know as I worked for a company on this
project) resulting in a reasonably painless Jan 1st 2000. Unfortunately many of
26

the "corrections" were of the "change-the-problem-date-to-few-years-in-thefuture" type, meaning that the bugs were not corrected, merely postponed. I
have been working as a programmer for thirty years now and remember what
people said in the seventies when I raised concerns about using only 2 digits for
the year. When I said this would cause a problem in the year 2000 I was told
that none of these systems would be around then. Seems like people are saying
the same things now for 2037. Some people never learn!!!!
-Paul
27
10. CONCLUSION
Still there is 26 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 26 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! : -
28
11. REFERENCES
http://computer.howstuffworks.com
http://en.wikipedia.org/wiki/Year_2038_problem
http://www.2038bug.com
29

Y 2 K 38

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Y 2 K 38

Uploaded by

Copyright:

Available Formats

Y2K38: Problems & Solutions

Y2K38: Problems & Solutions

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

2.2 Year 2010 problem

2.3 Programming Problem

Y2K38: Problems & Solutions

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

3 WHAT'S SO SPECIAL ABOUT 2038?

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

4. HOW THE TIME AND DATES ARE CALCULATED?

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 041 379 200

1-Jan-2038, 12:00:00 AM GMT

2 145 916 800

19-Jan-2038, 03:14:07AM GMT

2 147 483 647

Y2K38: Problems & Solutions

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

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

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

Y2K38: Problems & Solutions

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

6 WHAT IS THE IMPORTANCE OF TIME?

computation are almost unlimited in

applications, such as gun fire control, automatic navigation, missile

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

7. WHAT ARE THE CONSEQUENCES?

Y2K38: Problems & Solutions

7.1 Vulnerable systems

7.2 Data structures with time problems

file systems (like many in ode file systems still in use)

data bases (that have 32 bit time fields)

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

embedded factory, refinery control and monitoring subsystems

assorted medical devices

assorted military devices

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

Y2K38: Problems & Solutions

Fig 4: Step 3 error report

Department of Computer Science and Engineering, September 2011

Y2K38: Problems & Solutions

Fig 5: Step 4 error report