As with most
other computer system issues, Year 2000 issues can occur in any
level of technology. You should be aware of and understand what
levels of computer technology are used at your site and in your
applications. This will help you identify exposure points to investigate
for potential Year 2000 issues. It is important to ensure all technology
levels of your systems are Year 2000 compliant.
the specific chip architecture (e.g., Intel Pentium, Sun SPARC,
DEC Alpha, HP PA-RISC, etc.) and the machine's internal clock. The
system date is provided at the hardware level by the internal clock.
Many system clocks will return the value "1900" for Year
2000. These issues may be addressed by either firmware changes from
the hardware vendor or by operating system patches. Check your hardware
vendor's Web site and your operating system vendor's Web site for
Year 2000 issues.
system, including the file system, stores and manipulates dates.
The bulk of date processing and system date management occurs at
this level of your system. Even many recent operating systems require
upgrades to be fully Year 2000 compliant. Check your operating system
vendor's Web site for Year 2000 issues.
the set of files, DBMS databases, and spatial data used by your
applications. Dates can be stored in any of your databases. Most
of the time, you would use application-specific date types to store
and manage date information (e.g., an attribute item of type DATE
in your DBMS).
you implemented custom date types in your data files as type text
or numbers, you may have chosen to store only a two-digit value
for the year (e.g., "95" instead of "1995").
You should check your databases and applications to ensure that
their data management is Year 2000 compliant for date handling.
You should also ensure that any custom date storage and handling
you have implemented in your data schema is based on four-digit
years or that you have implemented an unambiguous method for processing
two-digit years stored in custom date fields.
and Run-Time Libraries
are software that run on your operating system and work with various
databases. ArcInfo and ArcView GIS are examples of Esri applications.
In addition to Esri software, you should ensure that other applications
you use are Year 2000 compliant.
also rely on run-time libraries and other embedded technology. Esri
has ensured that embedded technology in its applications is Year
2000 compliant for the functions utilized by our applications. However,
you should check for compliance of other applications and their
run-time libraries for technologies you have added to Esri applications.
are those built on top of Esri software or that utilize Esri software
components such as applications built with MapObjects or ArcInfo
ODE. It is definitely possible to build custom code that is not
Year 2000 compliant even though the underlying applications are
Year 2000 compliant. For example, any date handling in custom code
may use only two-digit years instead of four-digit years, and dates
could be reported by your custom code by appending the phrase "19"
in front of a two-digit year.
Year 2000 issues
are most likely to occur in custom code. You should establish guidelines
for testing your custom code to ensure that they are Year 2000 compliant.
Accept only Year 2000 certified applications from third party developers.
In order to
gain a further understanding of the various technology layers at
which Year 2000 issues may occur, you should check your operating
system vendor's Year 2000 Web site. Microsoft has a particularly
good Web site for understanding these technology layers. Visit the
ArcUser Jump Station for a direct link to this portion of the Microsoft
have five layers of technology. Year 2000 issues can occur at any
level of technology. It is important that you take steps to ensure
Year 2000 compliance at each level of your system.