>>>To me it seems like a very odd compile-time bug.
>>Why do you consider it a bug?
>
>The compiler should let any valid or invalid encoding go through because the encoding is determined by usage at runtime. I can do:
>
k = "dTest = {01/01/20}"
>&k>
>At runtime it will either work or not based on the strictdate setting.
>
>
>>It's pretty clear that it is telling you that you have used dates that are ambiguous.
>>You then have the option of changing a compile time switch to allow them or not.
>
>Consider this:
>Create a file called myfile.prg:
>
>SET STRICTDATE TO 0
>dTest = {01/01/2020}
>>
>From the command prompt type:
>
SET STRICTDATE TO 0
>compile myfile.prg
>* Compiles with no error
>
>SET STRICTDATE TO 1
>compile myfile.prg
>* Compile error
>
>SET STRICTDATE TO 2
>compile myfile.prg
>* Compile error
>
>
>The source code I'm compiling is valid. It would execute properly at runtime. Were I to swap out my explicit "dTest = {01/01/2020}" text above with the "k = 'dTest = {01/01/2020}'" code, and then execute "&k" in my source code it would be processed correctly.
>
>I just think it's wrong for VFP to consider the case of the date encoding at compile time when it could be a valid encoding based on settings when that line of code is reached at runtime. I think VFP should allow that determination to be made by strictdate settings when encountered in source code at runtime, and not by whatever the machine happens to be set to at compile time.
If you were using a different date like 01/02/2020, then you may end up with unexpected results when run on a computer that has different date settings. The compiler cannot tell if that date is 1st February or January 2nd, so it warns you.
