Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?
Yes, if during design time 4-digit years are always specified in date constants, and at run time one of the following actions is taken:
- 4-digit years are used for data entry.
- The developer writes resolution routines where appropriate to ensure that dates entered with 2-digit years are assigned to the desired century before being stored in tables.
How the product runtime handles dates:
Dates in variables and calculations are represented as 8-byte numeric values representing the number of days since some fixed date. In tables, date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or input masks on textboxes for data entry. This provides for full, unambiguous dates being stored independent of application logic.
Two-digit shortcut handling:
Dates with 2-digit years are always assumed to be in the 1900s. Even if Century is set to On, entering a 2-digit shortcut for a year will cause the date to be assumed to be in the 1900s.
Recommended practices to develop year 2000 compliant applications:
Set Century On
This feature of the product causes FoxPro to display dates with 4-digit years during data entry and display. The product default is Set Century Off. In the Off setting, it can be impossible to enter 4-digit dates and 2-digit dates are assumed to be in the 1900s.
Note: Regardless of how Century is set, users can enter dates with 2-digit years. These dates will be assumed to be in the 1900s.
Write Date Resolution Routines to Interpret Dates with 2-digit Years
If users will be entering dates with 2-digit years, developers can write date resolution routines to assign those dates to the desired century for the particular application. For instance, if dates with a year less than 75 are intended to be in the 2000s, the following code can be used in the Valid clause of a control on a form to automatically adjust the century portion of entered dates.
ldGetDate = table.datefield
IF YEAR(ldGetDate) < 1975
lcMonth = STR(MONTH(ldGetDate))
lcDay = STR(DAY(ldGetDate))
lcYear = STR(YEAR(ldGetDate)+100)
ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear)
REPLACE table.datefield WITH ldGetDate
ENDIF
Many FoxPro 2.6 applications use an Indirect READ strategy where the field values of a record are first SCATTERed to memory variables. Edits are then made directly against the memory variables. The memory variables are then GATHERed to write the data to the record. In that case the code might be adjusted as follows.
ldGetDate = m.datefield
IF YEAR(ldGetDate) < 1975
lcMonth = STR(MONTH(ldGetDate))
lcDay = STR(DAY(ldGetDate))
lcYear = STR(YEAR(ldGetDate)+100)
ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear)
m.datefield = ldGetDate
ENDIF
It Is Recommended that LUPDATE() Not Be Used
LUPDATE() returns the date that a table was last updated. This date is read directly from the .dbf table header. However, because only two digits of the year are stored in the table header, the date the table was last updated is assumed to be in the 1900s. Use the FDATE() function instead. A developer who wishes to use LUPDATE() must write a rollover routine to assign the 2-digit year it returns to the appropriate century.
Use 4-digit Years in Date Constants
Date constants of the form {mm/dd/yy} are valid. However, they are assumed to be in the 1900s. The recommended approach is to specify 4-digit years, e.g. {mm/dd/yyyy}.
Please refer to the white paper, "Year 2000 Date Support in FoxPro"
Common development errors dealing with year 2000 date issues:
Developers should take care to validate data entered as dates in addition to resolving ambiguous 2-digit year entries. Although FoxPro provides language and tools to help developers plan for year 2000 compliance, ultimately it is the responsibility of the application (and therefore the developer) to validate data before it is stored permanently in tables. For example, if a user entering warranty expiration dates for new computers enters 04/01/1902, the application should contain logic to reject this date, even though the date is exists and is year 2000 compliant.
Even if SET CENTURY ON is used and dates are displayed with four digit years, users can enter dates with 2-digit years. The date will be assumed to be in the 1900s.
Using dates with 2-digit years in code can lead to unexpected results. This practice should be avoided.
Please refer to the white paper, "Year 2000 Date Support in FoxPro"
Testing guidelines and recommendations:
Review the application and check the forms (screens) and reports for formatting and other issues related to dates.
Investigate the following areas of the product:
- Index tag expressions
- Report, label, and menu expressions
Investigate the code directly, searching for potential issues. The FoxPro Filer utility can be used to search for specific strings in source files, such as "CTOD(", that may cause problems.
Test the application under an actual year 2000 situation by setting the Windows, MS-DOS, Macintosh or Unix system to a date in the 2000s.
