Y2K Bug
• Discuss the specific project objectives of that technical system.
The Year (Y2K) 2000 problem, or the Millennium Bug, has arisen because back in the 1960s and 1970s,
computer programmers commonly used two digits to represent the year in both software and hardware,
e.g. 25/05/68 instead of 25/05/1968. When computer memory was incredibly expensive, and when
computer storage costs over a thousand times more than it does today programmers were forced to design
systems using as little memory and storage space as possible. In many cases, it was not just a matter of
costs: the memory and storage were so limited in available computers that they were simply not powerful
enough to run programs using” too much space”. By using two digits instead of four to represent the year,
two bytes can be saved for each date occurrence, which translates into tremendous savings in permanent
storage (disk, tape), volatile storage (memory) and CPU cycles (process two bytes as opposed to four
bytes). For example, a bank will hold information on every customer, which will include the date of all
transactions. If every customer has on average three transactions a week and the bank had 10,000,000
customers, then by using only two digit dates instead of four for the year, for just one of many dates held
for customers, 60,000,000 characters would be saved every week! Sixty megabytes might seem trivial
today but back in the 1960s and 1970s, it would not only cost a huge amount of money, but also cause
significant handling problems. And this is just for one of many dates that the bank has to handle each
week! So the programmers shorten the date to save memory, decrease the cost of computers and to
improve the performance of the computer.
• Discuss the failure reasons of that technical system in details.
Until the mid-1990s, this practice had not caused problems. However, the change in century could have a
very significant and adverse impact on the normal functioning of computer systems and on businesses in
general. As December 31, 1999, turned into January 1, 2000, computers might interpret December 31,
1999, turning into January 1, 1900. This practice has made it impossible to identify the year 2000:
computers reading only the last two digits of the year will either treat it as 1900 or shut down completely.
The flaw, faced by computer programmers and users all over the world on January 1, 2000, is also known
as the “Y2K bug” or the "millennium bug."
Because dates are used extensively in most information systems, the Millennium Bug can affect almost
every aspect of IT from large mainframes computers to smaller computers where there is a microchip
processor that uses dates for calculations, comparisons or other logical operations. From banks,
manufacturers and retailers, to universities and government agencies can be affected by the problem.
Even some safety critical systems, such as information systems controlling nuclear power stations, aero
planes, missiles, telecommunications networks, gas distribution systems and petrochemical refineries,
could fail if the bug is not fixed.
For example, at Tesco, canned food bearing the 2000 expiry date was recently rejected by a computer that
assumed it had been packed at the end of the last century. Ikea closed its Warrington branch over
Christmas in 1997 as it was having problems with 00-expiring credit cards. As the Millennium
approaches more and more problems of this sort have been encountered.
Banks, which calculate interest rates on a daily basis, faced real problems. Instead of the rate of interest
for one day, the computer would calculate a rate of interest for minus almost 100 years!
• Propose a hypothetical change in any of the work products to overcome the failure.
Some of the change that could overcome the Y2K bug are:
Date Field Expansion:
The most obvious program coding solution to the Year 2000 problem involves inserting two
extra characters in the date field (e.g. 98 becomes 1998) for all references to, and uses of, the two-digit
Year format. This is the standard method for the Year 2000 problem and is the only fully compliant and
‘permanent’ solution. The concept is simple to understand, but technically it can be very complex to
implement. The addition of two digits in a field displaces the position of all subsequent fields and
increases the amount of data that has to be stored. In addition, all existing data have to be converted to the
new format, and changes to input screen layouts and to all reports will need to be made to allow a four-
digit Year to be recorded.
Encoding:
Encoding involves compressing the required 4-digit century representation into the existing 2-digit Field.
This can be done in several ways.
First, the date Field can be encoded to use one (16-bit) binary value in place of the two 8-bit Year Fields
normally used for YY, so the 4-digit Year is encoded as a 16-bit (binary digit) Field. This would allow
values of the year up to 65 535 to be held.
Another encoding method is to create a century Field. This can be done in two ways. The first is to
replace the mmdd (month and day Fields) with ddd (the day numbers within the year), thus leaving an
additional character which can be used as a century indicator c. The century indicator can be encoded so
that 0=18 (for 1800), 1=19 (for 1900), 2=20 (for 2000) and so on up to 9=27 (for 2700). The code will be
changed from yymmdd to cyyddd. The second is to replace the two month characters with a one-character
month and a one-character century Field. The new month Field will use the values 1-9, a, b and c instead
of 1-12, giving an extra character Field that can be used for the century digit. The century indicator will
be encoded as above, e.g. 0=18, 1=19, etc. The code will be changed from yymmdd to cyymdd.
The third encoding method is to use different “arithmetic base” values. The normal 2 character Year Field
uses a base 10 and can hold a number up to 99. If the base is changed to 16 (hexadecimal) the two-
character Field could hold a value up to 255 (represented internally by 2 characters with 16 different
values 0-9, A, B, C, D, E, F), which would allow 156 (=255-99) extra years to be held in the same space.
The base could be extended to use base 62 using 0-9, a-z and A-Z. This could extend the range of the 2-
digit Year from 0-99 (base 10) or 0-255 (base 16), to 0-3843 (base 62).
There are several drawbacks to the encoding method. Changes to both data and program logic are
required; data must be converted before it can be displayed or printed otherwise the user will not
understand the output; and the encoding might not be compatible across all the applications that access
the data.
Windowing Strategies:
The principles of windowing are that a date field can be assumed to operate across a 100-year period. The
start and end-date of the 100-year period is selected to be convenient for the field in question e.g. for new
insurance policies launched in 1987, it would assume a 100-year window for any policy date to be 1987-
2086. The program logic would be amended to accommodate the date assumptions above. Dates less than
87 would assume the century 20 while dates greater than 86 would assume the century 19 (Bogle, 1998).
Windowing strategies avoid a lot of the drawbacks of the encoding and date field expansion methods, but
it cannot be used if the application deals with dates that span more than 100 years without additional
coding. No changes to the data on disk or to the existing data definitions within the programs are required
- only the logic of the program has to be modified.
• Design hypothetical Engineering Change Note.
Identification of what needs to be changed.
The year dates were stored by its last two digits only i.e. 1968 as 68 to save internal memory and disk
space. This introduced problem when date changes from 1999 to 2000.
Reason(s) for the change.
When date changed from 1999 to 2000 all the system having microchip processor that uses dates for
calculations, failed to operate properly.
Description of the change.
Selecting appropriate methods to address the Year 2000 problem is an important task with significant
financial and other implications, and different methods are relevant in different situations. The expansion
method is the only permanent solutions to the year 2000 problem but it has negative impacts on CPU
cycles and storage. Encoding and windowing methods allow the organization to conserve storage space
but programs will become more complex and will require extra CPU cycles. Windowing strategies will
not work for applications that need to keep dates in ranges wider than 100 years unless extra coding is
added.
List of documents (and in industry, the departments) affected by the change.
Approval of the change
Instruction about when to introduce the change
