>>>But understand that Naoto has explained why you had the problem. In general, you should avoid any code that relies on knowing the date format. If you must depend on it, then you need to set it when you need it.
>>>
>>>Tamar
>>
>>Hi Tamar,
>>
>>just out of curiosity.
>>How will one define a interface, let's say csv, and not define date format? I allways do something like
>>field n use blabla type date in the form YYYY-MM-DD in the interface documentation and SET DATE for the import.
>>If the import comes with DD.MM.YYYY it's like an alpha in a numeric field. Or would you parse each and every field? This could be a challenge - in time sense. :)
>
>So what I left out of my general warning was "wherever possible." Sometimes, you're presented with data that's already formatted and have to deal with it, like your CSV example. In that case, document the expected format and depending on the situation, either wrap the thing in TRY-CATCH, so you can report problems, or write the code that does the checking.
>
>Tamar

Hi Tamar,

the only thing is, that VFP is a bit fail safe on that. Problem comes if EMPTY() is allowed in import. VFP will read misformated date as empty. :)

But we don't need to go into deep with that. I think we both know the limitations. And I think we both could create a machine that can somehow search for it. If we realy need it. :)