>We are currently having discussions about FP 2.6 (Dos and Windows) and the Y2000. We have mutiple programs written in Fox that "the powers to be" say needs to be updated to VFP 5.0 to Y2000 compliant. I don't think going to VFP 5.0 will make the program Y2000 comp. We have expanded all screen input fields to show centuries with some error checking. We have also added a slide date routine (specs taken from IBM whitepaper) to deal with legacy data (We read info from a mainframe, no century stored). I know that using the date() function could cause problems but we do not use it for any calculations. What I would like to know is if there is a source that explains any short comings of FP 2.6 or VFP 5.0 and the Y2000, or any othe gotchas that we need to be made aware of.
>Thanks
Hi,
There is no Y2K problem in FP (all versions). Except lupdate() which never works true in year 2000 and after (fox keep it in header as three bytes for year, month, day -although could express whole range in 3 bytes by binary packing), there is no date problem in FP, any version. Also 2/29/2000 is correctly a leap year in FP. Any date in the range 01/01/100 - 12/31/9999 are handled correctly. Whatever the *set century* is FP -all versions- stores the date as YYYYMMDD. The problem is only with screen input. "4 digit year input" and "set century on" is the only care that should be taken to have full range support. If will use 2 digit entry then VFP has an option as "set century to XX rollover YY". Here if XX = 19 any 2 digit entry smaller than YY is assumed as 20YY. Also date math is valid in the given range. With "set century on" the converting functions also work true. In summary, for FP 2.x, all you need is to add a "set century on" at startup and let the date input fields have 4 digit entry.
Cetin