| Microsoft Year 2000 Readiness Disclosure
& Resource Center |
|
|
|
| Preparing Office Solutions for the Year
2000 |
|
Certifying
Data Entry Objects
A key
problem to address is how your program accepts dates. User interface
data entry in most applications does not require the entry of the
full four digits of the year. At worst, the application has input
masks or custom logic that forces two digit years only. At best, the
application probably uses the Control Panel Short Date setting which
will require only two-digit years.
Date
fields exposed to the user must be formatted to only accept four
digit years. This ensures that the operator (with proper training)
decides which century to use, not the computer. Similarly, anywhere
a date is shown, whether its on a form or report, that date must
display all four digits of the year. In places where the entry of
all four digits of the year is not practical (high volume,
heads-down data entry for example), you should create the logic that
supplies the century information.
The
first step is identifying any component of your application that
allows data entry of dates. This can include datasheets, forms,
queries with data entry capabilities, document objects, or
spreadsheets. Use the tools available in your application to control
date input. Investigate properties such as input masks, validation
rules and format properties. Where necessary, write or modify your
own validation routines to ensure that century data is being
correctly maintained. This step is critically important with 16-bit
applications.
Equally
important is the concept of date display. Any control that displays
data should have an explicit Format property setting that shows all
four digits of the year. This ensures that the operator can
spot-check dates and identify anomalies as data is being entered.
Identify Input or Logic that Assigns 'Hidden Meanings' to
Dates
A common
programming practice (and a poor one at that) is to assign a special
"hidden" meaning to dates. For example, the value of 9/9/99 is often
used to identify a piece of information that should never be erased,
or a date that never occurs, such as the expiration date of a
lifetime membership. Be sure to scan your application to ensure that
such values are neither accepted, nor acted upon.
Inherent Display Problems
In
certain cases, Microsoft Access and Microsoft Visual Basic display
date values in a non-consistent way related to 4-digit years. For
example, in Microsoft Access 97 or Microsoft Visual Basic 5, date
expressions bounded by the # sign do not display the way you may
expect. To see this behavior, open Microsoft Access 97, and type the
following into the Debug Window. (You can open the debug window at
any time by pressing Ctrl-G). Type in the following and press
[Enter]:
?#12/13/29#
The
value returned is:
12/13/2029
This
looks correct because all four digits of the year are shown, and the
assumption rule defined by OLEAUT32.DLL is used.
However,
if you type in:
?#12/13/30#
The
value returned is:
12/13/30
The real
"behind the scenes" value for Microsoft Access 97 is 1930. Note that
the full four digits of the year are hidden.
The same
problem occurs in the Microsoft Access property sheet on object
designs. For example, open a form in design view and click on a
control that has a DefaultValue property. In the property sheet's
DefaultValue property, type in #12/13/30#. You will see that as soon
as you press [Enter], Microsoft Access converts your input value to
#12/13/2030#. However, if you type in #12/13/2030#, Access leaves it
aloneùit shows the century.
While
this behavior may seem Year 2000 compliant because the full and
correct century is stored, the problem is that for years outside the
00-29 window, the century information is automatically and
unchangeably hidden.
|
