LAKKIREDDY BALIREDDY COLLEGE OF

ENGINEERING

Department of
INFORMATION TECHNOLOGY
(IT)

TECHNICAL
PAPER
ON
2K38 Problem

By:
Harish.k (3/4 Btech) Deepak.P(3/4 Btech)
Harish_karumuri@yahoo.co.in deepakit_1209@yahoo.in
REG NO:06761A1220 REG NO:06761A1209
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.
CONTENTS engendered widespread concern that
critical industries (such as electricity or

1. Introduction to Y2K problem. financial) and government functions

2. Causes of Y2K problem. would cease operating at exactly

midnight, January 1, 2000, and on other
3. Effects of Y2K problem.
critical dates which were billed as "event
4. Solution to Y2K problem. horizons". This fear was fueled by the
5. Introduction to 2K38 problem. attendant press coverage and other
6. Test for 2K38 problem. media speculation, as well as corporate
7. Causes of 2K38 problem. and government reports. Companies and
organizations world-wide checked and
8. Effects of 2K38 problem.
upgraded their computer systems. The
9. Solution to 2K38 problem.
preparation for Y2K thus had a
10. References. significant effect on the computer
industry. No significant computer
failures occurred when the clocks rolled
1. Introduction to Y2K problem:
over into 2000. Debate continues on
Y2K was the common
whether the absence of computer failures
abbreviation for the Year 2000 Problem.
was the result of the preparation
The abbreviation combines the letter Y
undertaken or whether the significance
for "year", and k for the Greek prefix
of the problem had been overstated. The
kilo meaning 1000; hence, 2K signifies
first recorded mention of the Year 2000
2000. It also named the Millennium Bug
Problem was on a Usenet Newsgroup on
because it was associated with a roll-
Saturday, January 19, 1985 by Usenet
over of the millennium. The Year 2000
poster, Spencer Bolles. It was speculated
problem (also known as the Y2K
that computer programs could stop
problem, the millennium bug, and the
working or produce erroneous results
Y2K Bug) was the result of a practice in
because they stored years with only two
early computer program design that
digits and that the year 2000 would be
caused some date-related processing to
represented by 00 and would be
operate incorrectly for dates and times
interpreted by software as the year 1900.
on and after January 1, 2000. It
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 telecommunications carrier,
Y2K flaw prevented them from reading found errors in the date
expiration dates properly. The stores had management part of the
to rely on paper transactions, as they do company's network.
when there are power failures or phone
4. Solution of Y2K problem
line failures, until replacement machines
arrived The solution, obviously, is

On 1 January 2000 to fix the programs so that they work

When January 1, 2000 arrived there properly. There are a couple of standard

were problems generally regarded as solutions:

minor. Problems did not always have to * Recode the software so that it

occur precisely at midnight. Some understands that years like 00, 01, 02,

programs were not active at that etc. really mean 2000, 2001, 2002, etc.

moment, and would only show up when * "Truly fix the problem" by using 4-

they were invoked. Not all problems digit placeholders for years and recoding

recorded were directly linked to Y2K all the software to deal with 4-digit dates

programming in a causal relationship; 5. Introduction to 2K38 problem

minor technology glitches occur on a "Year 2038" is frequently

regular basis, as anyone who ever had to abbreviated to "Y2038" or sometimes

reboot a personal computer will "Y2K38" in software professionals'

recognize. jargon.The year 2038 problem may

Reported problems include: cause some computer software to fail

before or in the year 2038. The problem
• In Ishikawa, Japan radiation-
affects programs that use the POSIX
monitoring equipment failed at
time representation, which represents
midnight, but officials said there
system time as the number of seconds
was no risk to the public.
since
• In Onagawa, Japan, an alarm
January 1, 1970. This representation is
sounded at a nuclear power plant
standard in Unix-like operating systems
at two minutes after midnight. In
and also affects software written for
Japan, at two minutes past
most other operating systems because of
midnight, Osaka Media Port, a
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 2038
19-Jan-2038, 03:14:07 AM GMT 2 147 -2147483648, Fri Dec 13 20:45:52
483 647 1901
An example C program
By the year 2038, the time_t
The follow C program demonstrates this
representation for the current time will
effect. It is strict ANSI C so it should
be over
compile on all systems that support an
2 140 000 000. And that's the problem.
ANSI C compiler.
A modern 32-bit computer stores a
#include <stdlib.h>
"signed integer" data type, such as
#include <stdio.h>
time_t, in 32 bits. The first of these bits
#include <unistd.h>
is used for the +ve/-ve sign of the
#include <time.h>
integer, while the remaining 31 bits are
used to store the number itself. The
int main (int argc, char **argv)
highest number these 31 data bits can
{
store works out to exactly 2 147 483
time_t t;
647. A time_t value of this exact
t = (time_t) 1000000000;
number, 2 147 483 647, represents
printf ("%d, %s", (int) t, asctime
January 19, 2038, at 7 seconds past 3:14
(gmtime (&t)));
AM Greenwich Mean Time. So, at
t = (time_t) (0x7FFFFFFF);
3:14:07 AM GMT on that fateful day,
printf ("%d, %s", (int) t, asctime
every time_t used in a 32-bit C or C++
(gmtime (&t)));
program will reach its upper limit. One
t++;
second later, on 19-January-2038 at
printf ("%d, %s", (int) t, asctime
3:14:08 AM GMT, disaster strikes.
(gmtime (&t)));
When a signed integer reaches its
return 0;
maximum value and then gets
}
The program produces the output: incremented, it wraps around to its
1000000000, Sun Sep 9 01:46:40 lowest possible negative value. This
2001 means a 32-bit signed integer, such as a
2147483647, Tue Jan 19 03:14:07 time_t, set to its maximum value of 2
147 483 647 and then incremented by 1, for ($clock = 2147483641; $clock <
will become -2 147 483 648. Note that 2147483651;$clock++)
"-" sign at the beginning of this large {
number. A time_t value of -2 147 483 print ctime($clock);
648 would represent December 13, 1901 }
at 8:45:52 PM GMT. So, if all goes For example, the output of this script on
normally, 19-January-2038 will Debian GNU/Linux (kernel
suddenly become 13-December-1901 in 2.4.22) (An affected system) will be
every time_t across the globe, and every # ./2038.pl
date calculation based on this figure will Tue Jan 19 03:14:01 2038
go haywire. And it gets worse. Most of Tue Jan 19 03:14:02 2038
the support functions that use the time_t Tue Jan 19 03:14:03 2038
data type cannot handle negative time_t Tue Jan 19 03:14:04 2038
values at all. They simply fail and return Tue Jan 19 03:14:05 2038
an error code. Tue Jan 19 03:14:06 2038
7. Test for 2K38 problem Tue Jan 19 03:14:07 2038
A quick check with the following Perl Fri Dec 13 20:45:52 1901
script may help determine if your Fri Dec 13 20:45:52 1901
computers will have problems (this Fri Dec 13 20:45:52 1901
requires Perl to be installed on your Test it now...
system, of course): steps...
#!/usr/bin/perl 1. Login to yahoo messenger
# Use POSIX (Portable Operating 2. Send instant message to anyone - fine
System Interface) use POSIX; its working...
# Set the Time Zone to GMT 3. Now, change your system date to 19-
(Greenwich Mean Time) for Jan-2038, 03:14:07 AM or above
date calculations. 4. Confirm weather your date is changed
$ENV{'TZ'} = "GMT"; 5. Again send instant message to
# Count up in seconds of Epoch time just anyone... Your YM crashes....
before and * * * YES ALL NETWORK BASED
after the critical event.
APPLICATION WILL NOT WORK small adjustment to the actual time the
NOW * * * bug expresses itself. This bug to cause
8. Effects of 2K38 problem serious problems on many platforms,
In May 2006, reports surfaced of especially Unix and Unix-like platforms,
an early Y2038 problem in the because these systems will "run out of
AOLServer software. The software time".
would specify that a database request 9. Solution to 2K38 problem
should "never" timeout by specifying a There is no easy fix for this
timeout date one billion seconds in the problem for existing CPU/OS
future. One billion seconds after combinations. Changing the definition of
21:27:28 on 12 Mary 2006 is beyond the time_t to use a 64-bit type would break
2038 cutoff date, so after this date, the binary compatibility for software, data
timeout calculation overflowed and storage, and generally anything dealing
calculated a timeout date that was with the binary representation of time.
actually in the past, causing the software Changing time_t to an unsigned 32-bit
to crash integer, effectively allowing timestamps
In the first month of the year 2038 to be accurate until the year 2106, would
C.E. many computers will encounter a affect many programs that deal with time
date-related bug in their operating differences.
systems and/or in the applications they Most operating systems for 64-bit
run. This can result in incorrect and architectures already use 64-bit integers
wildly inaccurate dates being reported in their time_t. The move to these
by the operating system and/or architectures is already underway and
applications. The effect of this bug is many expect it to be complete before
hard to predict, because many 2038. However, as of 2006, hundreds of
applications are not prepared for the millions of 32-bit systems are deployed,
resulting "skip" in reported time - many in embedded systems, and it is far
anywhere from 1901 to a "broken from certain they will all be replaced by
record" repeat of the reported time at the 2038. Despite the modern 18- to 24-
second the bug occurs. Also, may make month generational update in computer
some 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 file formats, such as the
common ZIP file format, which means it
can live on for a long time beyond the
life of the machines involved.
Using a (signed) 64-bit value introduces
a new wraparound date in about 290
billion years, on Sunday, December 4,
292,277,026,596. However, this problem
is not widely regarded as a pressing
issue. (A signed, 64-bit value is used in
Microsoft's proposed replacement for
time_t, dubbed __time64_t.).
All personal computers will likely to be
64-bit by the year 2038.But many
embedded systems may still be 32-bit or
less. Note that the large majority of
embedded systems today are still 8 or
16-bit. These could include microwave
ovens, wrist-watches, elevators, gas-
station pumps, car fuel injection
computers, radios etc.
There are orders of magnitudes more
small embedded systems in the world
than there are desktop computers.
Also, application software running on
64-bit systems may not use the POSIX
time_t type correctly. For instance, a C
programmer may inadvertently cast
time_t to 32-bits during a time
calculation; or implicitly knock off the
top 32 bits of a 64-bit time while storing
or retrieving the time.
An alert reader
was kind enough to point out that IBM
PC hardware suffers from the Year 2116
problem. For a PC, the beginning of time
starts at January 1, 1980, and increments
by seconds in an unsigned 32-bit integer
in a manner similar to UNIX time. By
2116, the integer overflows.
Windows NT uses a 64-bit integer to
track time. However, it uses 100
nanoseconds as its increment and the
beginning of time is January 1, 1601, so
NT suffers from the Year 2184 problem.
10. References
www.howstuff.ocm
www.wikipedia.com
The Year-2038 Bug Website
The Future Lies Ahead .