>>>Curious- why would you need this? If you have a date value already created in a variable, then it is not ambigous. Only constants are. The strict date format is not meant for user display...
>>
>>Settings table, .ini files and such, where data of various types should be represented as strings, and later converted from strings to real data, using Eval() - this should make them unambiguous. Namely, I have a table where I store some local config values, and it takes the dates when were some maintenance chores last done.
>
>Still unclear... why wouldn't you store the date in a date field?
>
>In the registry or ini files, I can see maybe, because he date would be stored in a string.

In this cfg file I have two memos - value and defaultvalue and in another I have oldvalue and newvalue (this one is used for auditing), so I can store any type of field into it (the value's type goes to another character field), and I'm doing fine with it. I wouldn't want to store dates in a setting dependable string, and writing a function like STOD() (I know we wrote one like that last year around here) seems to be not so elegant - and it still requires the CTOD(), which VFP6 will scream at. Eval() of something which is a neat strict date expression is something I want to store there (with type E for Eval()), and just close the box and forget about it.