The Year 2000 Problem
The
Information below about The Year 2000 Problem is from :
Class Solutions Ltd, Frerichs House, 14 Frerichs Close,
Wickford
Essex SS12 9QD, United Kingdom
Phone: +44 (0)1702 480675 / Fax: +44 (0)1702 480676
Email: [email protected] Web Site:
http://www.class-solutions.com
Read On… You'll find it very interesting
What is the Year 2000
Problem and How Does It Affect VB?
Abstract
The objective of this
document is to explain the meaning, history and implications of
the Year 2000 problem. In addition, a brief overview of the
impact that the Year 2000 will have on Visual Basic applications
is given as a means of convincing the reader that many date
related applications built using VB are probably not Year 2000
ready.
To fully understand the
details of the Visual Basic specific segments of this document,
the reader should possess some understanding of the language.
However, it should still be possible to get a feel for the
details with little or no VB experience. With regard to the
meaning, history and implications of the Year 2000 problem
generally, no technical knowledge is required. In fact, the first
section of the document is deliberately written with the lay
person in mind.
The Meaning of the Problem
Like all other tasks processed by computers, dates are simply
treated as numbers. To the outside world, date values can have
many varied formats and meanings but to the internal workings of
a computer, a date is just another set of numbers.
When the year part of a date is expressed using two digits such
as "4/5/96", the possible values for this year part
range between 00 and 99. Obviously, if the year part were
expressed using four digits, the values could range between 0000
and 9999.
In real life, if you add 1 to 99, the answer is 100. However, if
you tell a computer to add 1 to 99 and also specify that the
result must be no more than two digits, the answer is 0 or 00.
Now consider the effect of this numeric example on a date which
expresses year values with two digits. If you take the date
"4/5/99" and tell the computer to add 1 to the year
part, the result would look like "4/5/00". To most
humans, this date will suggest that the year part represents the
year 2000. But, to a computer (and here's the whole essence of
the problem), because the numeric representation of the year is
effectively zero, the year will be interpreted as 1900. In other
words, adding 1 year to 1999 will result in the year 1900!
The whole question is one of interpretation. Humans can usually
distinguish the intended value of a two digit year because of the
context of a date within its subject matter. For instance, if I
write "I hope to retire by 1/1/16", most people will
automatically assume that the year I hope to retire in is 2016.
If I said the same thing to a computer, the chances are that the
computer would interpret the same year as 1916.
So in essence, the Year 2000 problem can be defined as "the
inability of computer programs to correctly interpret the century
from a date which only has two year digits".
On the face of it, the specification of the problem appears to be
fairly simple, and so you may think is the solution. After all,
how much of a problem can two digits cause? As you will discover,
those two digits will be the provocation for the largest and most
costly exercise ever undertaken by any industry, world wide.
The History of the Problem
Almost without fail, the first question asked when somebody
learns about the Year 2000 problem is, "How was this allowed
to happen?". To most people, the thought that so much damage
could be done, by so many people, over such a long period of time
and completely undetected, is absolutely beyond belief!
The plain truth of the matter is that the Year 2000 issue has
always been there. Programmers have been aware of this problem
for years. Unfortunately for us, because of the "I won't be
around in 15 years, so it doesn't concern me" attitude
displayed by our predecessors, the problem has gone largely
unchecked in the IT industry. It's only because the likely
implications of the Y2K crisis are almost on top of us, and
because companies now stand to lose large amounts of money, that
the issue is now finally receiving the attention it deserves.
When examining the underlying reason for the cause of the
problem, two culprits arise. The first, and certainly the most
instrumental reason, is the issue of storage space in the 1960's
& 70's.
During this era, the cost of storing data was far from
insignificant. In an effort to minimise storage costs, most IT
projects would make a concerted drive to cut down the amount of
stored data required by an application. In this atmosphere of
conservation, no stone was left unturned. Numeric storage space
was drained to the smallest possible data type. Character storage
space was cut to the bone, and before long, dates would feel the
cut of the surgeon’s knife!
At the time, it was considered uneconomical to store the full
four digits of a year, including the century, when only the
two-digit year part was actually needed. Programs were able
continue processing dates as normal without ever understanding
the concept of a century, so why not take out the century part
altogether and save all that storage space? So, instead of
storing a date as "4/5/1968", programmers began to
store dates as "4/5/68".
Before long, in addition to being a good space saving idea, the
storage of dates with only two digits for the year was adopted as
the standard throughout the industry. No doubt, at the time, some
people will have raised doubts about the long-term effect of this
solution, but they were probably told that their systems would
not be in place for more than a few years. In fact, it's not
uncommon for corporate companies to have 20-year old legacy
applications in place now, which are core components of their
major systems.
Apart from the obvious problems with systems which are still
around today, by adopting the two-digit year as an industry
standard, the industry was virtually laying the foundations for a
future catastrophe.
Even as the cost of storage space became less of an overhead and
there was no longer any need to store dates with two digit years,
programmers continued to write applications which did so, partly
out of habit and partly because of the need for new applications
to share data in a common format with existing systems.
In addition to the cost of storage, the second probable reason
for using dates formatted with two digit years is the question of
user acceptance. In our every day life, it's usually quite rare
to complete any kind of date using four digits for the year.
Consider things like cheques, application forms, passports etc.
None of these require that the date contain a four-digit year. So
it's only natural for users to expect the same level of freedom
from computer software. In fact, in many IT departments it has
become common place for new application designs to be rejected by
users on the grounds that it is unreasonable to expect a user to
enter dates with four digit years!
From the users point of view, why should they be forced into
entering a full four digit year when the software is perfectly
capable of accepting and processing a short two digit year? It's
only now that the consequences of processing two-digit years are
really being thought through that the flaws in this argument are
beginning to show.
The Consequences of the Problem
OK, you now know the meaning of the problem and its history, but
what kind of an effect will this problem have? From the technical
perspective, there are two things that could happen to a rogue
application in the Year 2000.
The first sign that something many be wrong would be when the
whole system crashes! In some cases, a computer program will
simply not be able handle calculations using the number zero.
Without going into too much technical jargon, from a programming
point of view, this would be the equivalent of putting square
pegs into round holes.
In many ways, a complete melt down would probably be the better
of the two Year 2000 consequences. This is because a system crash
is tangible, it's something that you can see and hopefully
correct. Given a system failure, a maintenance programmer should
be able to identify the problem and go about fixing it.
The second possible consequence of the Year 2000 problem is far
more difficult to locate. In this situation, your system will
continue to work without falling over, this will give the
impression that nothing is wrong. However, while the program is
running, the results of date calculations will be completely
erroneous.
This second scenario is far more dangerous than the first because
errors will creep into the data long before anybody notices that
something is wrong. If your system provides data to other
systems, or the data calculated by your system is used over and
over again, the effects of miscalculated dates could be far
reaching. Because there is no tangible crash or system failure,
it could be weeks before the errors are picked up, by which time
systems, sub-systems and all kinds of external data could also be
corrupted.
Let's look at few examples of how ordinary business systems could
be affected by incorrectly calculated dates:
Suppose one function of your accounting system is to provide a
list of all invoices which have been outstanding longer than a
month for the purposes of the dept collection office. Brand new
orders may be given an invoice date of 2/2/00. In this case, the
accounting system would flag up these brand new invoices because
they have been outstanding for over 100 years! This scenario is
mild compared to some possibilities.
Suppose a finance company lends money to Mrs Jones, the loan was
created on February 2, 1996 and is set to run for a period of 5
years. The finance company's system therefore calculates that the
expiry date is February 2, 2001 and sets a flag to stop debiting
payments from her account after that date. The following day, the
system calculates that the expiry date of 02/02/01 has passed and
therefore decides not to take any money from Mrs Jones' account!
There are countless possible disaster scenarios just waiting to
happen to your systems when the century changes, and in some
cases, these problems will start to happen before the change of
the century.
The bottom line is, if your system calculates, processes or
stores any type of date related data, it is definitely at risk
from the Year 2000 issue.
Fixing the Problem
The first point is that there is no magic solution, silver bullet
or quick fix to the problem. Yes, it's true that we can put a man
on the moon, we can speak to people on the other side of the
planet and if we want, we can even blow the world up a thousand
times over. But, we can't fix the Year 2000 problem with one
swoop of a magic wand.
Because of the complexity and number of different business
applications, platforms, languages, technologies, programming
styles and business scenarios, it is impossible to come up with a
one-time, fix all solution. Instead, the problem needs to be
addressed by each company individually.
Unfortunately, the only way of being 100% certain that a given
application will function as expected into and beyond the next
century is to physically address every single line of code and
thoroughly test each function in the given application.
Regardless of the size and complexity of an application, it only
takes one single line of programming code to bring a system to
its knees! This is why each application needs to be looked at in
turn.
In a small single application environment, this will not pose
much of a task. However, the majority of businesses today rely
heavily on technology and business applications play a major part
in the success and future of most companies.
It is likely that most companies will need to scan hundreds of
thousands of lines of code, if not, millions. This will have a
massive impact on resources. The cost of fixing the Year 2000
problem can often be hard to justify to senior management,
especially when you consider that there is no tangible benefit to
be gained from the exercise with the exception of keeping the
company alive!
Visual Basic and the Year 2000
Because the cause of the problem stems back some twenty or thirty
years, the programming languages most effected by the Year 2000
problem are mainframe legacy languages such as COBOL. In fact,
it's probably fair to say that COBOL accounts for most of the
world’s business applications.
Because the Year 2000 problem is so easily identifiable with
COBOL and because Visual Basic is such a new language, many
people are under the impression that any system written using the
Visual Basic programming language is completely Year 2000 ready.
In reality, nothing could be further from the truth.
Visual Basic (16-bit) includes various date handling functions
and procedures which are intrinsic to the language, in most
cases, these functions are totally unaware of the Year 2000. In
fact, because of the implicit implication that these functions
will work into the Year 2000, and because of over confidence in
the language, applications built using Visual Basic are probably
more likely to cause problems than many other languages.
Microsoft has taken steps to correct these problems by
introducing fixes to these date functions in each of the major
new releases.
Visual Basic version 4.0 goes a long way towards fixing the date
problems and most date functions recognise the Year 2000,
however, VB 4.0/ 16-bit will always assume the current century
when entering dates so therefore processing short dates across
two centuries will not work.
VB 5.0 goes even further by introducing an industry accepted
technique known as windowing. This technique makes assumptions
about the intended century of a two-digit year. However, this
solution is also flawed because the window is a fixed window
which only interprets dates up until 2030. For instance, given
the date "01/01/32", VB 5.0 (and VB 4.0 32-bit) will
assume that the intended year is 1932.
This look at the language will focus on version 3.0 of Visual
Basic. The innovations introduced in later versions of VB are all
very exiting but the main task at hand is to serve the businesses
that are looking at systems already built with Visual Basic and
for the most part, those existing systems will have been built
using VB 3.0.
Probably the biggest single reason for non-compliance is the use
of Strings to handle dates as opposed to Variants of type V_DATE
(7) or actual Date data types (VB 4 & 5).
Many programmers use strings to store dates internally because
there is either a general reluctance to use Variants (based on
horror stories about the bad performance of Variants), or because
the programmers are simply unaware that variants can and should
be used.
The bottom line is that the Variant (7) was introduced especially
to handle dates and should be used as such.
If you speak to VB programmers about the Year 2000 problem, you
may be told that you don't have a problem because your VB
programs are using double precision numbers to store dates. This
is almost a valid point.
If you use VB’s CVDate() or DateValue() functions to assign
a date value to a Variant, VB will store the date internally as a
double precision number which indicates the number of days passed
since 30 December 1899. So for instance, if you examine the
internal representation of a DateValue of the date
"01/01/1900", the value will be 2 indicating that 2
days have passed since 30 December 1899. The following code
(using UK date formatting) demonstrates this:
MsgBox "Num days since 30/12/1899 " &
CDbl(DateValue("01/01/1900"))
Notice here that we are using the CDbl function which converts an
expression to a double precision number, this shows us how VB
stores the date internally.
Similarly, if you examine the internal representation of a
DateValue of the date "01/01/2000", the value will be
36526 indicating that 36,526 days have passed since 30 December
1899. The following code demonstrates this.
MsgBox "Num days since 30/12/1899 " &
CDbl(DateValue("01/01/2000"))
So far so good. It appears that using VB's CVDate() and
DateValue() functions to store dates as double precision numbers
will overcome the Year 2000 problem. However (and this is a big
however), there are two major issues concerning this technique.
The first issue concerns VB's inability to determine the intended
century of a two-digit year when it is initially expressed as a
string. For instance, consider the following code which is almost
identical to the previous example:
MsgBox "Num days since 30/12/1899 " &
CDbl(DateValue("01/01/00"))
Notice that we now use a two-digit year and that the result is 2
where you would expect it to be 36526. This proves that VB
(16-bit) can't be relied upon to correctly interpret the intended
century of a two-digit year.
Secondly, although your programmers are almost right when they
say that storing dates as double precision numbers causes Year
2000 compatibility, what has been overlooked is where the dates
came from in the first place.
With the exception of internal programmatic assignment (i.e.
Date1 = Date2), no other means of retrieving a date will ensure
that it arrives as a double precision number. In other words,
like it or not, all dates that your VB programs process will
start off as a String. If you think about it logically, the
external date interfaces to your VB application are all of the
String data type.
Where does your VB program get its dates from?
•Values from a Database – String (sometimes)
•Values from a file record - String •User input from a
text box - String •User input from a Calendar control -
String •User input from an InputBox - String
In fact, the only external interface to your VB application which
does supply the date as a double precision number is the system
date via either the Now() or Date() functions.
So what does this all mean? The point to all of this is that
although storing dates as double precision numbers should get
around the Year 2000 problem, because most, if not all date
values originate as strings, the intended century of a date can
and will be misinterpreted during the conversion from string to
Variant(7).
Often, the demonstration of a Year 2000 compliant example is
given as something like this:
Dim dtDate As Variant
dtDate = #1/1/2000#
In this date assignment, using the hash (#) to wrap an expression
forces the expression to a double precision value. The problem
here is that real programs don't do date assignments like this.
This example simply assigns a date literal to a variable. In a
real program, you would assign the value of a text box, database
column, calendar control, file record etc. to a variable. And
invariably, the data type of the date being assigned would be
String.
Let's look at a more realistic example of how a VB program would
assign a date value to a variable:
Sub cmdCalculate_Click ()
Dim dtStartDate As Variant 'Variant stores date in the text box.
'Assign the value in the text box to the local variable and
'convert it to a double precision number.
dtStartDate = CVDate(txtStartDate.Text)
'Display the internal representation of the double precision
'number.
MsgBox "Shows " & CDbl(dtStartDate) & "
days since 30/12/1899"
End Sub
In the above example, the date entered in the txtStartDate text
box is assigned to a local Variant(7) variable and converted to a
double precision number (using the CVDate function). When the
cmdCalculate button is pressed, the program displays the number
of days passed since 30 December 1899 based on the entered date.
There is no validation in this code so it is simple to break.
However, if you enter a date such as "01/01/00", you
will see that VB assumes that your date is 1 January 1900 - This
is regardless of the fact that you are storing the date as a
double precision number.
Again the point to all of this is to recognise that no matter how
you store your date values, they will almost all originate as
strings which can and will be incorrectly calculated. The short
comings highlighted here with the Visual Basic language are
really just the tip of the iceberg. Unfortunately, each of the
ten or so intrinsic date functions has its own set of quirks and
pitfalls. A detailed study of the limitations of these intrinsic
functions is outside the scope of this brief overview.
Hopefully, this short introduction to the Year 2000 problem has
given you some insight into the meaning, history, consequences,
remedies and technical, VB specific aspects of the very serious
Year 2000 problem.
Class Solutions Ltd are now distributing Visual DateScope 2000
which is a Visual Basic tool-set (including a date scanning
application and Year 2000 function library for remediation)
designed specifically to tackle the Year 2000 problem in VB
applications.
Click
here ... to go back to General Information page