Are you Ready for the Year 2000?
[2000: A Data Processing Odyssey]
CMAP (Centre de Mathématiques APpliquées) UMR CNRS 7641, École polytechnique, Institut Polytechnique de Paris, CNRS, France
france telecom, France Telecom R&D
[Site Map and Help [Plan du Site et Aide]]
[Real Numbers don't exist in Computers and Floating Point Computations aren't safe. [Les Nombres Réels n'existent pas dans les Ordinateurs et les Calculs Flottants ne sont pas sûrs.]]
[Please, visit A Virtual Machine for Exploring Space-Time and Beyond, the place where you can find more than 10.000 pictures and animations between Art and Science]
(CMAP28 WWW site: this page was created on 03/14/1997 and last updated on 05/15/2026 19:16:44 -CEST-)
[en français/in french]
Abstract: Many programs ignore the first two digits of years. During the last night of
1999 many computers will then travel back to the past. The consequences
could be catastrophic. The very problem lies in the number of checks
(more than 100 billions Cobol lines) and updates to be done.
Leading analysists estimate Year 2000 costs will exceed $1000 billions.
Keywords: A2M,
An 2000,
An 2038,
Bogue,
Bug,
Bug de l'An 2000,
Bug de l'An 2038,
Bugix,
Millenium Bug,
Year 2000 Bug,
Year 2000 Problem,
Year 2038 Bug,
Year 2038 Problem,
Y2K,
Y2K Bug,
Y2028,
Y2028 Bug.
Contents of this page:
WARNING:
The author of this page
is solely responsible for its contents.
FOREWORD:
IN PROGRESS/EN COURS
ADVERTISEMENT:
On 03/08/1999, "Le Bug de l'An 2000 - Comprendre l'informatique jusqu'à ses défaillances",
Bernard Aumont and Jean-François COLONNA,
Flammarion, Paris, France.
1-INTRODUCTION:
Same fears than for the Year 1000... But this time the
sky ain't gonna fall over our heads, that's
our computers that could become insane during the
last night of 1999 (31/12/1999-01/01/2000) and maybe earlier...
1.1-Non linear natural phenomena:
For many natural phenomena, a very small cause
can have huge consequences, for example, an avalanche or again
the so-called "butterfly" effect
(Edward Lorenz).
1.2-Non linear artificial phenomena:
Techniques and Sciences give us artificial "objects" having the same property.
The Lorenz attractor is one of the best known non linear
system; it can be used to display
the sensitivity to initial conditions.
The disastrous Ariane 501 flight (on 06/04/1996) is an excellent
example of a such phenomenon, even if it has nothing to do with
a date problem.
Here is third example with a pay slip
after an increase in salary; everything has a negative value!
1.3-Computer Science in the sixties:
1.4-Computers everywhere:
Computers are everywhere; computers are more than useful;
computers cannot be disconnected; computers are fully interconnected.
Then, the whole set of computers is a huge non linear
system that can behave chaotically or in an unforeseeable way.
2-THE YEAR 2000 PROBLEM:
2.1-General causes:
2.2-Specific causes:
(non exhaustive list)
(for the sake of simplicity, let us call
century number
the first two digits of a four-digit year,
when it is true only for the last year of each century)
2.2.1-The maltreated Century:
2.2.1.1-The lost Century:
The century number is almost
sytematically ignored
(1997, for exammple,
is stored as 97).
This is the case of the national INSEE
number in France.
2.2.1.2-The only one Century:
Very often a "19" is printed before a 2-digit
year and this "19" cannot be changed...
2.2.1.3-The garbage Century:
Sometimes there is enough room to store
the century
number, but unfortunately this
is used for something else...
2.2.1.4-The different date formats:
Depending on some specific criteria (geographical,
economical,...),
many formats are available. Thus,
for example,
"XX/TT/ZZ" can be understood
as "YY/MM/DD" or as "DD/MM/YY"
("YY" is here for the 2-digit year,
"MM" is the month and "DD" is the day).
Many programs have to chose by them'selves
what is the appropriate format of a given date;
to do
that they must compare "XX" to "31":
if "XX" is greater than "31",
then "YY/MM/DD" is chosen and "DD/MM/YY"
otherwise.
for example "20/03/97" will mean "20/03/??97"
(without forgetting the ambiguity about "97":
does it
mean "1897", "1997",...?).
Then, what is the meaning
of "10/03/05": "05/03/1910",
"10/03/1905",
"05/03/2010", "10/03/2005",
or something else?
2.2.2-The unreachable Years:
Many programs make use of some particular 2-digit
years (for example "00" or again "99")
as indicators (meaning, for example, "end of file"
or again "free space").
These years are then unreachable; watch for the year 1999...
2.2.3-Computers have a finite capacity:
The current date (as well as the time) is computed
using a counter that is incremented automatically
and periodically.
More than oftem this counter has a very finite capacity;
when its overflow occurs, the system "goes back"
to the past
(for example, 'GPS' receivers
make use of a 10-bit week counter that will
rollover at midnight, August 21-22, 1999
-Electronic Design 11/04/1996 page 18,
Datamation 06/1997 page 31-
!).
2.2.4-Strings of Numerical Caracters are not Numbers:
Arithmetic computations with strings of caracters
cannot be done as with numbers.
For example, using the ASCII code,
"1989"+1
does not equal "1990" but "198:" (this problem was
already encountered with some italian credit cards).
2.2.5-Leap Years:
A leap year is created every fours years (its remainder
must be equal to 0 when divided by 4). But the first
year of any century is not a leap year,
except for every forth century (its remainder
must be equal to 0 when divided by 400). Then the
year 2000 will be a leap year.
This last fact is often omitted (as it is the case
with old releases of Excel).
Thus, the so-called Y2K bug
is much more complex than believed...
2.3-Culprits:
Finalement, serions-nous tous responsables?
3-SOME CONSEQUENCES:
3.1-Back to the Past:
The year [20]00 (for example) will be understood
as 1900 (or again 1970, 1980,...
depending of some specific choices of the manufacturers).
3.2-Duration computations:
With 2-digit years the compuation of durations could
be wrong (for example, someone born in [19]80
will be 99-80=19 years old in [19]99 and, for example,
00-80=-80 years old in [20]00).
3.3-Periodical actions:
Regularly scheduled actions could start at a wrong date;
as a matter of fact, 01/01/1900 was a monday,
then 01/01/[20]00 could be said to be a monday too
(when it will be a saturday). Some processing could be delayed,
some security acces systems could take inappropriate initiatives (as
to unlock the doors of a classified building),...
3.4-Temporal Relationships:
They could be wrong and imply that,
for example, [19]99 > [20]00.
3.5-The duration of life of digital objects:
Documents, objets,... could be detroyed
(for example, a backup done on 01/01/[20]00 could
be declared to be done before the one done on
31/12/[19]99 and then could be erased,
or again, an invoice sended in [19]99 and unpaid in [20]00
could be declared hopeless,...).
3.6-Arithmetics:
Some processings will be aborted; as a matter of fact,
hash-coding algorithms divide
by the year (to provide a fast acces to data).
This is the case for some random-number generators.
With the year [20]00, there will be division by 0
when a 2-digit year is used...
3.7-Object Naming:
It is a common useful practice to name objects using the date and time.
For example, a file created on 07/11/1997 11:40:38 could be
named "19970711114037". When the four digits of the year are used,
there are no risks for "collisions" (ie. identical names produced at
different times) or for erroneous relationships; but when only two
digits are used, theses risks exist.
3.8-Economical and Social Consequences:
Some are more sensitive (trade, insurance, bank,...)
to date malfunctions than others (scientific research, for example).
For the more sensitive that will not be ready in time, economical
disasters (with obvious social consequences) can be forecasted.
4-THE SOLUTIONS:
5-THE PROBLEMS:
5.1-The Scale of the Work:
5.1.1-The Nightmare:
The hugest project never encountered. The needed tasks
must be performed in parallel with other developments
(for example, the introduction of the Euro currency).
The dead line cannot be changed (31/12/1999 or worst,
31/12/1998)!
Are we already too late?
5.1.2-The programs:
100.000.000.000 of lines to be checked (most are
Cobol) , unfortunately, at least 4% of
them are definitely lost.
The primary consequence of this huge number
is the impossibility to scrap aging applications
containing Year 2000 problems and to develop new
applications that are Year 2000 compliant: it is
too late...
5.1.3-Computers are everywhere:
From video-tape recorders, to nuclear submarines.
Then, do not forget the Embedded Systems.
Everything is almost connected to everything.
Then, you must be ready in time, but it is
not sufficient: your suppliers, your
clients, your collaborators,...
must be ready in time too...
5.2-There is no miraculous solution!
In particular,
the fastidious inventory process
cannot be avoided.
5.3-Maintenance:
It is only a maintenance task concerning obsolete programs!
5.4-The method:
5.4.1-The Inventory of programs and computers:
Be aware that computers are everywhere...
5.4.2-To Check:
Every program and every computer must be checked, but
unfortunately:
5.4.2.1-Automation is impossible:
Due to the lack of common
structures and common vocabularies,
due to unacceptable things (for example
using {peter,paul,mary}
instead of
{year,month,day}-),...
5.4.2.2-The Documentation:
Frequently, it is wrong,
uncomplete, or non-existent...
5.4.2.3-About source codes:
At least 4% of them are definitely lost;
for the 96% that still exist, it appears
that some of them are not up to date (due to
direct patches on binary load modules and/or
libariries)!
5.4.3-To Correct:
5.4.3.1-The Compatibility:
Temporary interfaces should be defined
between what has been corrected and what
has not yet been corrected.
Moreover, some 20 year old programs
are no longer allowed to be compiled because
they are no longer compatible with the new
compilers...
5.4.3.2-To Manage the Risks:
For each application,
a priority must be defined (a high priority
must be given to applications that are of vital
importance for men as well as for the
company). Unfortunately, the 0 risk
does not exist; the consequences of
fixing that cannot be made in time
must be evaluated.
5.4.3.3-Cobol Programmers Wanted:
Are they enough programmers around the world
to do the job? Where are the Cobol programmers
gone? Where are the best ones?
5.4.3.4-How to Test and What to Test?
How to be sure eveything has been fixed
without losing anything? Is there enough
time to test? Do not forget that test cases
have to be repaired too...
How to simultaneously add
new fonctionnalities and new softwares?
Besides well-known dates to be checked
(01/01/2000, 02/29/2000,...)
some others could be the source of
serious difficulties; for example:
- 09/09/1999 when "9/9/99"
plays a specific role,
- 03/01/2000 for it will
be the first week day
of the year 2000,
- 01/03/2000 that will
be a wednesday,
- 10/10/2000 that is
the first day needing
8 characters,
- etc...
Unfortunately, this list is not
exhaustive...
5.4.3.5-Consequences:
It is a well known fact that updating
a program, introduces most of the time
new defaults. Then, fixing the
Year 2000 problem is a risky job: about
10% of Year 2000 repairs will inject
new bugs or refects.
5.4.3.6-Do not Forget:
Paper forms,
screen forms,
the training of people,...
5.5-Related problems:
5.5.1-Speed Degradation:
Repairs of aging applications will induce a degradation
in data center throughput; the most probable estimate
of the loss is in the order of 20%. Thus the processing
power has to be increased; it is true as well for the
disk space.
5.5.2-Who will pay?
Leading analysists estimate Year 2000 costs will exceed
$1.000.000.000.000 (and remember that it is always
underestimated)...
5.5.3-Who will be liable for the expectable damages?
5.5.4-In Europe:
The new european currency (the Euro) is
coming at the same time and it does not help.
A recent report by the UK's
Computing Services and Software Association
says that the creation of the European monetary
system could be delayed: the IT changes needed could
take five years to implement (see
IT Issues Could Threaten European Monetary Union
in IEEE Computer, 02/1997, page 19).
5.5.5-In France:
It seems we are late. Many concerned people ignore
(or underestimate) the problem.
5.6-Some examples:
6-WHAT CAN YOU DO?
6.1-To become aware of the problem and of its scale:
Everybody must understand the problem is real...
6.2-To Explain the Problem to concerned People:
We must inform concerned people that are ignoring or
underestimating the problem.
6.3-To Check our environment:
You must check your tools (accounting softwares,
your backup programs, your security processes,
your software licences,
the various programs you use -make commande under UNIX-,...).
6.4-To Question:
You must ask our suppliers what is the state of their products
regarding the Year 2000 problem as well as their projects about
future releases (never take for granted their
yes, it works: check it yourself...).
6.5-About New Contracts:
Every new contract (about computers or anything else
that could make use of digital components...) must contain
something like Year 2000 compliance.
The IEEE Computer Society is currently working on a first standard
definition of Year 2000 compliant technology
(see Year 2000 compliance
in IEEE Micro, 09/1997, page 6).
In the 03/1998 issue of IEEE Computer,
a draft standard defines Year 2000 compliant as:
Techonology, including but not limited to,
information technology, embedded systems, or any
other electro-mechanical or processor-based system,
when used in accordance with its associated documentation,
is capable of accurately processing, providing, and/or
receiving date data from, into, and between the twentieth
and twenty-first centuries, and the years 1999 and 2000,
including leap year calculations; provided that all other
technology properly exchanges date data with it.
6.6-To be more vigilant:
It is suggested to check more than usual invoices,
bank listings,...
6.7-To suggest:
It could be time for an international normalization of the
date; then, we could seize the opportunity to implement
it progressively in programs updated and make it
mandatory for all new developments. For example,
the date could be memorized and manipulated as
a signed 32-bit counter (this allows counting from
-2147483648 to +2147483647) in relation to a starting date;
this last one could be 01/01/0001 UT
(or 12/20/1582,...), the number of days
since that day being less than 732000 (=366*2000) and
then compatible with the counter capacity and with
any future use (it is noteworthy that this counter is independent
of any foreseeable reform of the calendar)! Then, two
conversion functions would be needed
(counter-->date and date-->counter);
all useful date formats would be accepted and an
optional argument looking like a C 'printf()' format
would allow any conversion.
Finally, normalized test cases should be provided...
7-THE NEWS:
- On 02/19/1998, the central business district of Auckland
(New-Zealand) was struck by a complete power failure. It took more
than five weeks to resume full service. This was due to an unusually
hot summer and not to a computer failure. But this incident reminds
us how vulnerable we are...
- On march 1998, the IEEE Computer published that the US
Federal Aviation Administration will not solve its Y2K problems
by 01/01/2000. This could lead to degraded safety, delayed
flights and customer inconvenience. The General Accounting Office
(GAO) said the FAA is so far behind schedule that even the basic
inventory is not completed. The FAA infrastructure is made of
18.000 old susbsytems and 65.000.000 lines of code.
- President of the USA Bill Clinton and United Kingdom Prime Minister
Tony Blair have agreed to place the Y2K problem on the formal
agenda of the next G7 economic summit, which is
being held in Great Britain in May 1998.
8-CONCLUSION:
Copyright © Jean-François COLONNA, 1997-2026.
Copyright © France Telecom R&D and CMAP (Centre de Mathématiques APpliquées) UMR CNRS 7641 / École polytechnique, Institut Polytechnique de Paris, 1997-2026.
