SH As Hi 1

DEPARTMENT OF COMPUTER ENGINEERING
Regional College For Engineering Research and Technology- Jaipur

Seminar Session- 2010 - 2011
A
SEMINAR REPORT
ON
Y2K38
By
Name of the student:

Shashi bala
Submitted in partial fulfillment for the Award of degree of

Bachelor of Technology
Submitted To:-
Navin Goyal
(HOD CS)
A
SEMINAR REPORT
ON
Y2K38
By
Name of the student:

Shashi bala
Guided by
Mr. Name of guide
Designation
Preface
This project is basically about 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.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..
CERTIFICATE
This is to certify that the Seminar entitled “Y2K38” has been carried out by
Shashi bala under my guidance in partial fulfillment of the degree of Bachelor
of Technology in Computer Engineering of Rajasthan Technical University
during the academic year 2010-2011. To the best of my knowledge and belief
this work has not been submitted elsewhere for the award of any other degree.
Guide Examiner Head of the Department
Mr.Amit Bairwa
ACKNOWLEDGEMENT
I express my sincere thanks to Mr.Amit Bairwa, who is an Assistant Professor in Computer
Science Department.,
For guiding me right form the inception till the successful completion of the Seminar. I
sincerely acknowledge him/her/them for extending their valuable guidance, support for
literature, Critical reviews of training and the report and above all the moral support
he/she/they had provided to me with all stages of this Seminar.
Shashi bala
INDEX
1. Introduction
2. Early Problems
2.1 Emulation and Megafunctions
2.2 Machines Affected
2.3 Software Issues
3.What is the year 2038 bug?
3.1 Unix
3.2 Php Code
3.3 Unix date command
4. The Year-2038 Bug
4.1 C program Code
4.2 Will 64-bit save us?
5. Year 2000 problem
5.1 9 September 1999
5.1.1 Leap years
5.2 Year 2010 problem
5.4 Confusion between day and year
6. Programming solutions
6.1 Date expansion
6.2 Date re-partitioning
6.3 Windowing
7.Cost
8. Unix billennium
8.1 UTC basis
8.2 History
8.3 Coordinated Universal Time
9. Time to Panic About Y2K38?
9.1 Much Scarier
9.2 A Non-Issue
10. The Future is 64Bit
10.1 Consequence
11 .Is Unix Millennium Bug / Y2K38 / Year 2038 problem still an issue?
CONCLUSION
REFERNCES
Seminar guide interaction report
Seminar observers Report
1. INTRODUCTION
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.
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.
The Y2K38 problem has been described as a non-problem, given that we are
expected to be running 64-bit operating systems well before 2038. Well, maybe.
2. Early problems
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.
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.
Unix internal time is commonly stored in a data structure using a long int
containing the number of seconds since 1970. This time is used in all time-
related processes such as scheduling, file timestamps, etc. In a 32-bit machine,
this value is sufficient to store time up to 18-jan-2038. After this date, 32-bit
clocks will overflow and return erroneous values such as 32-dec-1969 or 13-
dec-1901.
2.1 Emulation and Megafunctions
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 in 1999 as an Embedded Function within Altera
programmable devices. Such embedded functions present a serious maintenance
problem for Y2K38 and similar rollover issues, since the package part number
and other markings typically give no indication of the internal function.
2.2 Machines Affected
Currently (March 1998) there are a huge number of machines affected. Most of
these will be scrapped before 2038. However, it is possible that some machines
going into service now may still be operating in 2038. These may include
process control computers, space probe computers, embedded systems in traffic
light controllers, navigation systems etc. etc. Many of these systems may not be
upgradeable. For instance, Ferranti Argus computers survived in service longer

than anyone expected; long enough to present serious maintenance problems.
Unix time is safe for the indefinite future for referring to future events, provided
that enough bits are allocated. Programs or databases with a fixed field width
should probably allocate at least 48 bits to storing time values.
Hardware, such as clock circuits, which has adopted the Unix time convention,
may also be affected if 32-bit registers are used.
The Y2K38 threat is more likely to result in aircraft falling from the sky,
glitches in life-support systems, and nuclear power plant meltdown than the
Y2K threat, which is more likely to disrupt inventory control, credit card
payments, pension plans etc. The reason for this is that the Y2K38 problem
involves the basic system timekeeping from which most other time and date
information is derived, while the Y2K problem (mostly) involves application
programs.
2.3 Software Issues
Databases using 32-bit Unix time may survive through 2038. Care will have to
be taken to avoid rollover issues.
3.What is the year 2038 bug?

The Year 2000 problem is understood by most people these days because of the
large amount of media attention it received.
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 . 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.
The standard 4-byte format assumes that the beginning of time is January 1,
1970, at 12:00:00 a.m. This value is 0. Any time/date value is expressed as the
number of seconds following that zero value. So the value 919642718 is
919,642,718 seconds past 12:00:00 a.m. on January 1, 1970, which is Sunday,
February 21, 1999, at 16:18:38 Pacific time (U.S.). This is a convenient format
because if you subtract any two values, what you get is a number of seconds
that is the time difference between them. Then you can use other functions in
the library to determine how many minutes/hours/days/months/years have
passed between the two times.
If you have read How Bits and Bytes Work, you know that 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 January 19,
2038. On this date, any C programs that use the standard time library will start
to have problems with date calculations.
This problem is somewhat easier to fix than the Y2K problem on mainframes,
fortunately. 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 (unlike most mainframe programs, which
did not standardize their date formats or calculations). So the Year 2038
problem should not be nearly as hard to fix as the Y2K problem was.
In the first month of the year 2038 C.E. many computers will encounter a date-
related bug in their operating systems and/or in the applications they run. This
can result in incorrect and grossly inaccurate dates being reported by the
operating system and/or applications. The effect of this bug is hard to predict,
because many applications are not prepared for the resulting "skip" in reported
time - anywhere from 1901 to a "broken record" repeat of the reported time at
the second the bug occurs. Also, leap seconds may make some small adjustment
to the actual time the bug expresses itself. Starting at GMT 03:14:07, Tuesday,
January 19, 2038, I fully expect 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 (including 911 emergency services), banking system
crashes, 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. In case you think we can sit on this issue for another 30 years before
addressing it, consider that reports of temporal echoes of the 2038 problem are
already starting to appear in future date calculations for mortgages and vital
statistics! Just wait til January 19, 2008, when 30-year mortgages will start to be
calculated.
3.1 Unix
What makes January 19, 2038 a special day? Unix and Unix-like operating
systems do not calculate time in the Gregorian calendar, they simply count time
in seconds since their arbitrary "birthday", GMT 00:00:00, Thursday, January 1,
1970 C.E. The industry-wide practice is to use a 32-bit variable for this number
(32-bit signed time_t). Imagine an odometer with 32 wheels, each marked to
count from 0 and 1 (for base-2 counting), with the end wheel used to indicate a
positive or negative integer. The largest possible value for this integer is 2**31-
1 = 2,147,483,647 (over two billion). 2,147,483,647 seconds after Unix's
birthday corresponds to GMT 03:14:07, Tuesday, January 19, 2038. One second
later, many Unix systems will revert to their birth date (like an odometer
rollover from 999999 to 000000). Because the end bit indicating
positive/negative integer may flip over, some systems may revert the date to
20:45:52, Friday, December 13, 1901 (which corresponds to GMT 00:00:00
Thursday, January 1, 1970 minus 2**31 seconds). Hence the media may
nickname this the "Friday the Thirteenth Bug". I have read unconfirmed reports
that the rollover could even result in a system time of December 32, 1969 on
some legacy systems!
3.2 Php Code

<?php
$date = '2040-02-01';
$format = 'l d F Y H:i';
$mydate1 = strtotime($date);
echo '<p>', date($format, $mydate1), '</p>';
?>
With luck, you’ll see “Wednesday 1 February 2040 00:00″ displayed in your
browser. If you’re seeing a date in the late 60’s or early 70’s, your PHP
application may be at risk from the Y2K38 bug!
DateTime does not suffer from Y2K38 problems and will happily handle dates
up to December 31, 9999. People might have paid off their mortgage by then!
It may not be worth upgrading existing applications, but you should certainly
consider the DateTime class when planning your next project.
In computer science and computer programming, system time represents a

computer system's notion of the passing of time. In this sense, time also
includes the passing of days on the calendar.
System time is measured by a system clock, which is typically implemented as a

simple count of the number of ticks that have transpired since some arbitrary
starting date, called the epoch. For example, Unix and POSIX-compliant
systems encode system time as the number of seconds elapsed since the start of
the Unix epoch at 1 January 1970 00:00:00 UT. Windows NT counts the
number of 100-nanosecond ticks since 1 January 1601 00:00:00 UT as reckoned
in the proleptic Gregorian calendar, but returns the current time to the nearest
millisecond.
3.3 Unix date command
System time can be converted into calendar time, which is a form more suitable
for human comprehension. For example, the Unix system time 1000000000
seconds since the beginning of the epoch translates into the calendar time 9
September 2001 01:46:40 UT. Library subroutines that handle such conversions
may also deal with adjustments for timezones, Daylight Saving Time (DST),
leap seconds, and the user's locale settings. Library routines are also generally
provided that convert calendar times into system times.
Closely related to system time is process time, which is a count of the total CPU
time consumed by an executing process. It may be split into user and system
CPU time, representing the time spent executing user code and system kernel
code, respectively. Process times are a tally of CPU instructions or clock cycles
and generally have no direct correlation to wall time.
File systems keep track of the times that files are created, modified, and/or
accessed by storing timestamps in the file control block (or inode) of each file
and directory.
Most first-generation PCs did not keep track of dates and times. These included
systems that ran the CP/M operating system, early models of the Apple II, and
the Commodore PET, among others. The IBM PC was the first widely available
personal computer that came equipped with date/time hardware built into the
motherboard, and subsequent add-on peripheral boards included real-time clock
chips with on-board battery back-up. Prior to the widespread availability of
computer networks, most personal computer systems that did track system time
did so only with respect to local time and did not make allowances for other
time zones.
With current technology, all modern computers keep track of local civil time, as
do many other household and personal devices such as VCRs, DVRs, cable TV
receivers, PDAs, pagers, cell phones, fax machines, telephone answering
machines, cameras, camcorders, central air conditioners, and microwave ovens.
4. The Year-2038 Bug
The year-2038 bug is similar to the Y2K bug in that it involves a time-wrap
problem not handled by programmers. In the case of Y2K, many older machines
did not store the century digits of dates, hence the year 2000 and the year 1900
would appear the same.
Of course we now know that the prevalence of computers that would fail
because of this error was greatly exaggerated by the media. Computer scientists
were generally aware that most machines would continue operating as usual
through the century turnover, with the worst result being an incorrect date. This
prediction withstood through to the new millennium. Affected systems were
tested and corrected in time, although the correction and verification of those
systems was monumentally expensive.
There are however several other problems with date handling on machines in
the world today. Some are less prevalent than others, but it is true that almost all
computers suffer from one critical limitation: Most programs work out their
dates from a perpetual second counter - 86400 seconds per day counting from
Jan 1 1970. A recent milestone was Sep 9 2001, where this value wrapped from
999'999'999 seconds to 1'000'000'000 seconds. Very few programs anywhere
store time as a 9 digit number, and therefore this was not a problem.
Modern computers use a standard 4 byte integer for this second count. This is
31 bits, storing a maximum value of 231. The remaining bit is the sign. This
means that when the second count reaches 2147483647, it will wrap to
-2147483648.
The precise date of this occurrence is Tue Jan 19 03:14:07 2038. At this time, a
machine prone to this bug will show the time Fri Dec 13 20:45:52 1901, hence
it is possible that the media will call this The Friday 13th Bug.
4.1 C program Code
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.
01.#include <stdlib.h>
02.#include <stdio.h>
03.#include <unistd.h>
04.#include <time.h>
05.
06.int main (int argc, char **argv)
07.{
08. time_t t;
09. t = (time_t) 1000000000;
10. printf ("%d, %s", (int) t, asctime (gmtime (&t)));
11. t = (time_t) (0x7FFFFFFF);
13. t++;
15. return 0;
16.}
The program produces the output:
1.1000000000, Sun Sep 9 01:46:40 2001

2.2147483647, Tue Jan 19 03:14:07 2038
3.-214783648, Fri Dec 13 20:45:52 1901
Y2K38, or the Unix Millennium Bug, affects PHP and many other languages
and systems which use a signed 32-bit integer to represent dates as the number
of seconds since 00:00:00 UTC on 1 January 1970. The furthest date which can
be stored is 03:14:07 UTC on 19 January 2038. Beyond that, the left-most bit is
set and the integer becomes a negative decimal number — or a time prior to the
epoch.
Yes, it’s 28 years away and I’m sure many of you think it’s ridiculous to worry
about it now. However, developers thought that way about the Millennium bug
the 1970’s and 80’s. Also, any web application which handles long-term future
events could be at risk. For example, a typical mortgage runs for 25 years.
Pensions and savings plans can be far longer.
4.2 Will 64-bit save us?

Probably. If you’re using a 64-bit OS with a compiled 64-bit edition of PHP,
your application shouldn’t be affected. I’d recommend you test it, though. A
signed 64-bit number gives a maximum future date which is 21 times greater
than the current age of the universe — 292 billion years, give or take a day or
two.
You can probably sleep at night if you’re convinced your financial application
will always be installed on a 64-bit system.
5. Year 2000 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 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
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.
5.1 9 September 1999
Even before 1 January 2000 arrived, there were also some worries about 9
September 1999 (albeit lesser compared to those generated by Y2K). Because
this date could also be written in the numeric format 9/9/99, it could have
conflicted with the date value 9999, frequently used to specify an unknown
date. It was thus possible that database programs might act on the records
containing unknown dates on that day. Somewhat similar to this is the end-of-
file code 9999, used in older programming languages. While fears arose that
some programs might unexpectedly terminate on that date, the bug was more
likely to confuse computer operators than machines.
5.1.1 Leap years
Mostly, a year is a leap year if it is evenly divisible by four. A year divisible by

100, however, is not a leap year on the Gregorian calendar unless it is also
divisible by 400. For example, 1600 is a leap year, but 1700, 1800 and 1900 are
not. Some programs may have relied on the oversimplified rule that a year
divisible by four is a leap year. This method works fine for the year 2000
(because it is a leap year), and will not become a problem until 2100, when
older legacy programs will likely have long since been replaced. For
information on why century years are treated differently, see Gregorian
calendar.
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.
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 0–9 as 0x0–0x9. 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.
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
of 20 million bank cards became unusable, and with Citibank Belgium, whose
digipass customer identification chips stopped working.
Main article: Year 2038 problem
The original Unix timestamp (time_t) stores a date and time as a 32-bit integer
representing the number of seconds since January 1, 1970. During and after
2038, this number will exceed 32 bits, causing the Year 2038 problem (also
known as Unix Millennium bug, or Y2K38). To solve this problem, many
systems and languages have switched to a 64-bit timestamp, or supplied
alternatives which are 64-bit.
5.4 Confusion between day and year
Ambiguity and errors can rise when different methods of ordering a

day/month/year sequence are used by different entities. For example, 30/11/05
could result in the interpretations of November 5, 2030; November 30, 2005,
May 30, 2011, or even May 11, 2030. Any abbreviated year in 2001-2031 can
lead to the error. Standardising the date format (as in ISO 8601: yyyy-mm-dd) is
difficult due to the open nature of writing, international differences, and human
behaviour.
6. Programming solutions
Several very different approaches were used to solve the Year 2000 problem in
legacy systems. Three of them follow:
6.1 Date expansion
2-digit years were expanded to include the century (becoming 4-digit years) in
programs, files, and databases. This was considered the "purest" solution,
resulting in unambiguous dates that are permanent and easy to maintain.
However, this method was costly, requiring massive testing and conversion
efforts, and usually affecting entire systems.
6.2 Date re-partitioning
In legacy databases whose size could not be economically changed, 6-digit

year/month/day codes were converted to 3-digit years (with 1999 represented as
099 and 2001 represented as 101, etc.) and 3-digit days (ordinal date in year).
Only input and output instructions for the date fields had to be modified, but
most other date operations, and whole record operations required no change.
This delays the eventual roll-over problem to the end of the year 2900.
6.3 Windowing
2-digit years were retained, and programs determined the century value only
when needed for particular functions, such as date comparisons and
calculations. (The century "window" refers to the 100-year period to which a
date belongs.) This technique, which required installing small patches of code
into programs, was simpler to test and implement than date expansion, thus
much less costly. While not a permanent solution, windowing fixes were
usually designed to work for several decades. This was thought acceptable, as
older legacy systems tend to eventually get replaced by newer technology.
The Y2K issue was a major topic of discussion in the late 1990s and,
predictably, showed up in most popular media. A number of "Y2K disaster"
books were published such as Deadline Y2K by Mark Joseph. Movies such as
Y2K: Year to Kill capitalized on the currency of Y2K, as did numerous TV
shows, comic strips, and computer games.
7. Cost
The total cost of the work done in preparation for Y2K is estimated at over 300
billion US dollars. There are two ways to view the events of 2000 from the
perspective of its aftermath:
This view holds that the vast majority of problems had been fixed correctly, and
the money was well spent. The situation was essentially one of preemptive
alarm. Those who hold this view claim that the lack of problems at the date
change reflect the completeness of the project, and that many computer
applications would not have continued to function into the 21st century without
correction or remediation.
8. Unix billennium
The Unix billennium is the point in time represented by a Unix time value of
109: 01:46:40 UTC on September 9, 2001. Some programs which stored
timestamps using a text representation encountered sorting errors, as in a text
sort times after the turnover, starting with a "1" digit, erroneously sorted before
earlier times starting with a "9" digit. Affected programs included the popular
usenet reader KNode and e-mail client KMail, part of the KDE desktop
environment. Such bugs were generally cosmetic in nature and quickly fixed
once problems became apparent.
The problem also affected many 'Filtrix' document-format filters provided with
Linux versions of WordPerfect; a patch was created by the user community to
solve this problem, since Corel no longer sold or supported that version of the
program.
The Unix Billennium is sometimes described as "109 seconds after the Unix
epoch". This is not quite correct, because Unix time is not a purely linear count
of seconds: "109 non-leap seconds after the Unix epoch" would be a more
accurate description.
The name is a portmanteau of "billion" and "millennium", recalling the year

2000 bug. The name is not very logical as billennium should rather mean a
billion years. "Gigasecond" would be a more apt term.
Unix time, or POSIX time, is a system for describing points in time, defined as
the number of seconds elapsed since midnight proleptic Coordinated Universal
Time (UTC) of January 1, 1970, not counting leap seconds. It is used widely,
not only in Unix-like operating systems, but also in many other computing
systems and file formats. It is neither a linear representation of time nor a true
representation of UTC (though it is frequently mistaken for both), as it cannot
represent standard UTC leap seconds (e.g. December 31, 1998 23:59:60),
although otherwise the times it represents are UTC. Unix time may be checked
on some Unix systems by typing date +%s on the command line.
8.1 UTC basis
The present form of UTC, with leap seconds, is defined only from January 1,
1972 onwards. Prior to that, since January 1, 1961 there was an older form of
UTC in which not only were there occasional time steps, which were by non-
integer numbers of seconds, but also the UTC second was slightly longer than
the SI second, and periodically changed to continuously approximate the Earth's
rotation. Prior to 1961 there was no UTC, and prior to 1958 there was no
widespread atomic timekeeping; in these eras, some approximation of GMT
(based directly on the Earth's rotation) was used instead of an atomic timescale.
The precise definition of Unix time as an encoding of UTC is only

uncontroversial when applied to the present form of UTC. Fortunately, the fact
that the Unix epoch predates the start of this form of UTC does not affect its use
in this era: the number of days from January 1, 1970 (the Unix epoch) to
January 1, 1972 (the start of UTC) is not in question, and the number of days is
all that is significant to Unix time.
8.2 History
The earliest versions of Unix time had a 32-bit integer incrementing at a rate of
60 Hz, which was the rate of the system clock on the hardware of the early Unix
systems. The value 60 Hz still appears in some software interfaces as a result.
The epoch also differed from the current value. The first edition Unix
Programmer's Manual dated 3 November 1971 defines the Unix time as "the
time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second".
8.3 Coordinated Universal Time
Coordinated Universal Time (UTC) is a time standard based on International

Atomic Time (TAI) with leap seconds added at irregular intervals to
compensate for the Earth's slowing rotation. Leap seconds are used to allow
UTC to closely track UT1, which is mean solar time at the Royal Observatory,
Greenwich.
The difference between UTC and UT1 is not allowed to exceed 0.9 seconds so,
if high precision is not required, the general term Universal Time (UT) may be
used.
In casual use, when fractions of a second are not important, Greenwich Mean
Time (GMT) can be considered equivalent to UTC or UT1. Saying "GMT"
often implies either UTC or UT1 when used within informal or casual contexts.
In technical contexts, usage of "GMT" is avoided; the unambiguous
terminology "UTC" or "UT1" is preferred.
Time zones around the world can be expressed as positive or negative offsets
from UTC as in this list; UTC replaced GMT as the basis for the main reference
time scale or civil time in various regions on 1 January 1972.
9. Time to Panic About Y2K38?

The Y2k38 bug was detected a few months ago, but there was no actual testing
done to prove that this will affect our current computers. Now this bug can
actually start to cause some damage. To test this we can try using any chatting
client either AOL Messenger , MSN Messenger, Yahoo Messenger, Trillian, or
Gaim will do. As for my testing this bug affected all of these applications
(windows). To test these for yourself do the following: First double click on the
time in the bottom right-hand corner. Change the date to something after
January 19, 2038 (2039 is fine!). Now start up any of the chatting clients
mentioned above. Try sending a message to someone else (or to yourself if it
supports it). As soon as you do this, the entire program should crash within a
few seconds and will display some sort of error message. It will then bring up a
message asking to send an error report or debug. (The only application I tested
that actually survived this bug was Skype. It just let me send the message to
who ever I want and it never complained, but the rest crashed.) From the actual
technical problem, apparently as soon as the year 2038 strikes, all certain
computers will immediately get confused and switch the date to December 13,
1901 from January 2038. Please post any other programs you have experienced
this problem with in the comments. Hope people don’t wait until the last minute
to find a solution to this problem.
In a nutshell, the year 2038 problem, as it is also known, is that most Unix-like
operating systems represent time as the number of seconds since January 1,
1970. On 32-bit systems, that second count is a signed 32-bit integer. What that,
in turn, means -- unfortunately for us all -- is that the latest time that can be
represented is 03:14:07 UTC on Tuesday, January 19, 2038.
Slashdot's bloggers can always be counted upon to be on top of potential crises

in the geek world, and a good thing too, because there's been very little mention
of the impending crisis elsewhere. But sure enough, alert Slashdot blogger
kdawson sounded the alarms on Tuesday with a post calling attention to the
Y2K38 phenomenon, and his was followed by no fewer than 530 comments.
9.1 Much Scarier
"Most of the Y2K problems were just display errors, not bugs in the actual
calculations going on under the scenes," wrote jandrese. "2038 is much scarier
and is a lot more difficult to fix."
The best way to fix the problem is likely to switch to a 64-bit representation of
time, but "thus far not too many people have made moves in that direction,"
jandrese added. "Switching to 64 bits is not as easy as it might sound, either,
since lots of programs use timestamps and many of them make assumptions as
to the size of their time fields."
Not everyone, however, is sure that the situation is quite that dire.
9.2 A Non-Issue
"The Y2K38 thing is really interesting, I think. I don't know how much of an
impact it will have, but a lot of Unix code is built on those old timestamps,"
Slashdot founder Rob Malda told LinuxInsider. "I guess it's better we find out
now than wait."
Even more so: "I think it's a non-issue in most cases," blogger Kevin Dean
asserted. "*nix is built around free software, and the one variant that isn't, Unix
'proper,' is essentially irrelevant. The 32-bit addressing should also be addressed
by the move now to 64-bit systems."
Some legacy applications might be "minimally affected by this," Dean told

LinuxInsider, "but I think the fact that those people have uneditable,
unsupported legacy applications that are critical to their operating is MUCH
more of an issue than the date being off. This is nothing more than a low-
severity bug and will be fixed without much effort."
10. The Future is 64Bit

The future of all computers is 64Bit, yes and without doubt servers and web
applications should be going that way to. If you are a lucky one to already be
running under the 64Bit architecture with a 64Bit complied PHP then you are
actually fine.
The reason 64Bit works is that a signed 64Bit number gives a maximum future
date which is 21 times greater than the current age of the universe, 292 Billion
Years.
You can probably sleep well if you know your financial application is going to
be running on a 64Bit system.
UNIX keeps track of time in a 4-byte integer that represents the number of
seconds after January 1, 1970 12:00:00.
For example, a time of 60 represents the date January 1, 1970 12:01:00.
A 4-byte integer has a maximum value of 2,146,483,547. This time (known

as maximum time) corresponds exactly to January 19, 2038 3:14:07.
This explains why UNIX programs in large, were pretty much unaffected by
the Y2K bug - since it kept track of time in units of seconds. However, its
own version of Y2K will occur a second past the maximum time.
10.1 Consequence
At exactly January 19, 2038 3:14:08 (one second past the maximum UNIX
time), one of two things can happen to programs that keep track of time with
this format. It will either crash and stop functioning altogether, or it will
rollback time to the beginning of UNIX time: the first minute of 1970.
What this means for computer programs and systems that haven't been fixed
depends on the program itself. The consequences can be similar those
predicted with the Y2K bug.
Many pieces of software that involve future dates (i.e. Calendars, Investment
calculators etc.) are already experiencing problems with the 2038 bug, being
unable to involve any dates past 2038.
Also, some calculations that involve averaging dates have begun to fail as
well. For example, if an algorithm adds two dates together and then divides
by 2 to find the middle date, it would fail.
Many popular software updates recently are already addressing this issue. If
your favourite software isn't, do not worry, the bug will occur in over 30
years. During that time, it is very likely that most systems will have gone to
a 64-bit operating system (where this problem is averted for over 290 billion
years - much past the lifespan of the sun).
For those systems or programs still on a 32-bit platform, the bug will indeed
cause problems, but fixing the problem will not be difficult due to the nature
of it. It will not require recoding how dates are stored in a program as was
the case with Y2K, dates will merely be required to be stored in a primitive
type with larger precision.
As for programs that involve averaging dates, the simplest solution would be
some basic alegebraic manipulation: to divide the dates by two before
adding them together.
11.Is Unix Millennium Bug / Y2K38 / Year 2038 problem still

an issue?
Unix Millennium Bug / Y2K38 / Year 2038 problem may cause some
computer software to fail before or in the year 2038. The problem affects
all software and systems that 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.[2] 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.
A search shows that a fix was found in 2008, but I thought the problem
targeted almost all 32-bit systems & 64-bit systems like way Way WAY
INTO THE FUTURE?!?
Conclusion
Year 2038 problem will more likely result in air traffic control disasters, life-
support systems failure, and power grid meltdown than the year 2000 problem.
The year 2000 problems often involved higher-level application programs,
disrupting inventory control, credit card payments, pension plans, and the like.
The 2038 problem may well cause more serious problems because it involves
the basic system timekeeping functions from which most other time and date
information is derived. Databases using 32-bit Unix time may survive through
2038, and care will have to be taken in these cases to avoid rollover issues.
Some problems related to the year 2038 have already started to show
themselves.
Some Unix vendors have already started to use a 64-bit signed time_t in their
operating systems to count the number of seconds since GMT 00:00:00,
Thursday, January 1, 1970 C.E. Programs or databases with a fixed field width
should probably allocate at least 48 bits to storing time values. 64-bit Unix time
would be safe for the indefinite future, as this variable won't overflow until
2**63 or 9,223,372,036,854,775,808 (over nine quintillion) seconds after the
beginning of the Unix epoch - corresponding to GMT 15:30:08, Sunday,
December 4, 292,277,026,596 C.E. This is a rather artificial and arbitrary date,
considering that it is several times the average lifespan of a sun like our solar
system's, the very same celestial body by which we measure time. The sun is
estimated at present to be about four and a half billion years old, and it may last
another five billion years before running out of hydrogen and turning into a
white dwarf star.
An organization called The Open Group (formerly X/Open), which maintains

the Unix specification and trademark, has a number of programming
recommendations which should be followed by developers to deal with the year
2038 and other problematic dates.
Bibliography
1. www.geekyard.com
2. udayms.wordpress.com
3. uzzal.wordpress.com
4. lockergnome.net
5. news.tigerdirect.com
6. serverfault.com
SEMINAR GUIDE INTERACTION REPORT
Phase Interaction Remarks

Topic Decision Mr.Amit Bairwa
Resources search Mr.Amit Bairwa and

Mr.Robil Varshney
Compilation of resources Mr.Amit Bairwa
Abridged report Mr.Amit Bairwa
Rough draft Mr.Amit Bairwa and

Mr.Raja Bhati
Intermediate draft Mr.Amit Bairwa and

Mr.Robil Varshney
Signature
Seminar Guide
Seminar Observer’s Report

Name Observations Remarks/Marking (10)
Mr.Amit Bairwa
Mr.Robil Varshney
Mrs.Yogita punjabi
Mr.Raja Bhati
Mr.Naveen Goyal

SH As Hi 1

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

SH As Hi 1

Uploaded by

Copyright:

Available Formats

DEPARTMENT OF COMPUTER ENGINEERING

Regional College For Engineering Research and Technology- Jaipur

Name of the student:

Submitted in partial fulfillment for the Award of degree of

Name of the student:

Guide Examiner Head of the Department

I express my sincere thanks to Mr.Amit Bairwa, who is an Assistant Professor in Computer

he/she/they had provided to me with all stages of this Seminar.

In May 2006, reports surfaced of an early manifestation of the Y2038 problem

2.1 Emulation and Megafunctions

2.2 Machines Affected

upgradeable. For instance, Ferranti Argus computers survived in service longer

2.3 Software Issues

3.What is the year 2038 bug?

Most programs written in the C programming language are relatively immune to

3.2 Php Code

$format = 'l d F Y H:i';

echo '<p>', date($format, $mydate1), '</p>';

In computer science and computer programming, system time represents a

System time is measured by a system clock, which is typically implemented as a

3.3 Unix date command

4. The Year-2038 Bug

4.1 C program Code

The following C program demonstrates this effect. It is strict ANSI C so it

The program produces the output:

1.1000000000, Sun Sep 9 01:46:40 2001

4.2 Will 64-bit save us?

5. Year 2000 problem

5.1 9 September 1999

5.1.1 Leap years

Mostly, a year is a leap year if it is evenly divisible by four. A year divisible by

5.2 Year 2010 problem

The main source of problems was confusion between hexadecimal number

5.3 Year 2038 problem

Main article: Year 2038 problem

5.4 Confusion between day and year

Ambiguity and errors can rise when different methods of ordering a

6.1 Date expansion

6.2 Date re-partitioning

In legacy databases whose size could not be economically changed, 6-digit

The name is a portmanteau of "billion" and "millennium", recalling the year

8.1 UTC basis

The precise definition of Unix time as an encoding of UTC is only

8.3 Coordinated Universal Time

Coordinated Universal Time (UTC) is a time standard based on International

9. Time to Panic About Y2K38?

Slashdot's bloggers can always be counted upon to be on top of potential crises

9.1 Much Scarier

Some legacy applications might be "minimally affected by this," Dean told

10. The Future is 64Bit

A 4-byte integer has a maximum value of 2,146,483,547. This time (known

11.Is Unix Millennium Bug / Y2K38 / Year 2038 problem still

Further, while most programs will only be affected in or very close to

An organization called The Open Group (formerly X/Open), which maintains

SEMINAR GUIDE INTERACTION REPORT

Phase Interaction Remarks

Resources search Mr.Amit Bairwa and

Abridged report Mr.Amit Bairwa

Rough draft Mr.Amit Bairwa and

Intermediate draft Mr.Amit Bairwa and

Seminar Observer’s Report

You might also like