Hi David,

VFP is correct about what it reports. It's your use of data constants that causes this "buggy" behavior. date constants (ie. {...}) are evaluated at compile time, not runtime. Thus, how these dates are interpreted depends on the SET DATE setting that was active when you saved and compiled this program.

From the results you get, it's SET DATE TO MDY, and that means the first number is always interpreted as a month, doesn't matter what you change SET DATE to in your program. Since 1998 is an invalid month, it returns 0, in both other cases it's 1.

Since this has been a problem for many developers, Microsoft added the strict date feature to VFP 5. By preceeding the date with "^" you tell VFP that the following date is in YMD notation, no matter what SET DATE is during compiling. I'd strongly recommend you to get used to this notation to avoid problems in the future.

In VFP 6 with the default setting of SET STRICTDATE, VFP reports all other data constants as error.

Christof


>I thought the date problem I was having was restricted to FPW. But try this in a VFP program
>

>Test.prg
>set date mdy
>x= {1/8/1998}
>? month(x) && => 1
>set date ymd
>x= {1998/8/1}
>? month(x) && => 0
>set date dmy
>x= {1/8/1998}
>? month(x) && => 1
>
>x= {^1998/08/01}
>? month(x) && => 8
>set date mdy
>* EOF

>
>Pretty awful.