The LA Fox Developer Newsletter

July 1999

Year 2000 Date Support in

Microsoft FoxPro

by Robert Green

Microsoft Corporation, 1999

For Microsoft FoxPro® and Microsoft Visual FoxPro® develop-

ers, the transition to the year 2000 presents a number of issues

to be aware of, so that the applications you build will be fully

year 2000 compliant and function with the behavior you desire

after the turn of the century.

This article is meant to help you identify year 2000 issues that

may be present in your applications and to suggest solutions

you can provide.

It has always been easy to create year 2000 compliant applica-

tions in all versions of FoxPro. The latest versions of Visual

FoxPro include enhanced language features to make this

process even easier. Because FoxPro is a development lan-

guage and application tool, it has always been possible for

developers to create applications that will not perform as desired

after the turn of the century. If you have identified and resolved

potentially ambiguous dates during the development and testing

of your applications, they may already be year 2000 compliant.

If not, this paper will help you

do so.

If you have Visual FoxPro 6.0,you may also want to consult the

Help files. They contain detailed

that make it even easier to identify potential year 2000 issues in

your FoxPro applications.

Ambiguous Dates

As a FoxPro or Visual FoxPro developer, you probably already

know that year 2000 issues are nothing more than a special

case of data ambiguity. When you eliminate ambiguous

references to dates, your applications will become year 2000

compliant—as long as you are using the unambiguous dates

appropriately for your application. So, what do we mean by date

ambiguity?

Look at a date you might have stored in a program file:

{l0/1 1/12)

Obviously, this date may have different meanings to different

people:

If you are a librarian cataloging old books, you may assume that

the date represents October 11, 1912.

If you are working for a US brokerage firm calculating yields on

30-year bonds, you may interpret the date as October 11, 2012.

Finally, if you are an economist in Europe forecasting economic

trends, you might see this date as November 10, 2012.

In fact, the Date constant{1 0/11/12) could represent October

11, 1912, October 11, 2012, November 10, 1912, November 12,

1910, or November 12, 2010 depending on factors such as

context and local date standards. In FoxPro and Visual FoxPro,

the value represented by this ambiguous Date constant is

determined by the settings of the SET CENTURY and SET

DATE commands.

Because FoxPro and Visual FoxPro are developer products

used for creating database applications around the world in a

variety of contexts (e.g., storage of historical as well as contem-

porary data), developers need to understand how the rich date-

related language affects their applications.

It is straightforward to determine, by reading the product docu-

mentation and entering some sample dates, how FoxPro and

Visual FoxPro products resolve ambiguous dates by default For

example, the FoxPro 2.6 manual states that the default for SET

CENTURY is OFF and that all dates with 2-digit years are

interpreted as in the 20th century (l9xx). This may be fine for

the librarian above who is entering dates for antique books.

However, the stockbroker might want to change SET CENTURY

to ON so that full 4-digit year dates may be entered. (This is the

simplest method for any application because it eliminates entry

of ambiguous dates). If you permit 2-digit dates to be entered

with SET CENTURY ON, you can determine how they will be

interpreted if you wish to change the default behavior for the

version of FoxPro you are using. By default in FoxPro 2.6, for

example, 2-digit dates are interpreted with SET CENTURY ON

to he in the 20th centyry (1 9xx). You can change this by writing

validation or resolution cbde.

Note:

Even with SET CENTURY OFF, developers can easily

write validation or resolution code (e.g., Valid snippet, Valid

event, LostFocus event, etc.) to resolve input of ambiguous

dates, because FoxPro tables store the full unambiguous date.

In summary, if you can eliminate ambiguous dates from your

FoxPro or Visual FoxPro application and ensure that you are

handling the unambiguous dates correctly, your applications

should be year 2000 ready.

How To Use This Document

Your approach to dealing with year 2000 compliance in your

applications should include a two-step process of Detection and

Correction. This paper is organized around these concepts and

is designed to help you understand what you need to do to

ensure that your applications will function in the manner your

customers expect after 1999.

Detection

The most important, and perhaps most time-consuming, part of

resolution is detection. You need to examine your code, includ-

ing forms, reports, labels, tables, views, and query fields for

unambiguous date formatting. Of course, data entry and display

controls also need to be examined. You also need to check for

(Con't, page 7)

Page 6