The DATE field
While I applaud Ed's desire to share helpful information with SPCUG members, unfortunately the suggestions he makes are both unnecessary and dangerous. I have spent most of the last three years correcting just this kind of problem for the California Department of Transportation and have extensive experience with the possibilities.
Users of dBase generally know that dates usually display in the default format like "09/19/99" and that a date field takes eight spaces in the .dbf file itself. Many users assume that the date is stored in the file the same way it is displayed, as "09/19/99." This is a misconception. Looking at the file with a hex editor or with Vern Buerg's popular LIST.COM, you will see that the date is saved with the century value, as "19990919". As a result, there is absolutely no problem with Y2K, whether these files are in dBase, FoxPro, Clipper, or any of the other programs that use .dbf files.
The only problem with Y2K in dBase is that the default data entry format for a date field permits the user to enter just two digits for the year. This forces the program to decide what century to use for the missing digits. In all programs that use dBase files, the command SET CENTURY ON, inserted at the beginning of the file, expands the display to permit input of four numbers for the year thus solving the century problem. The dates will still be saved properly in the file.
All Xbase programs (dBase, Clipper, FoxPro, Arago, Quicksilver, etc.) will assume "19" for the century years without using SET CENTURY ON (or other commands which vary according to the language used). This problem is covered thoroughly in an article I wrote for Sacra Blue some time back, which is available here.
|
Ed's idea of converting the date fields to character values and expanding the field to 10 characters is not necessary since the dates are appropriately recorded in the record's date field. Further, using a date field provides automatic validation of the date value. It is impossible to enter an invalid date (e.g., "15/45/8018") into a date field. But you can put anything into a character field.
Further, even if you are careful enough to put only proper dates into the character field, there are multiple problems. For example, take the checkbook file. If you try to sort it by date, the usual sort for a checkbook, you'll discover that the dates, now character fields instead of date fields, sort by ASCII value. What you get is that all January 01 dates are listed first. Then come January 02 dates, etc. So February 29 of the year 2000 ("02/29/2000") will be listed before June 13 of 1884 ("06/13/1884").
The easy and safe way to deal with any Y2K problems in any Xbase program is to put SET CENTURY ON as the first line of the program. The only problem this will give you is a possible need to redesign some screens to allow the extra numbers. But all the math, all the indexing and everything else will work as expected.
I'd be happy to help out anyone who has any further questions on this issue.
|
