>>>>>>Hi,
>>>>>>
>>>>>>Can you change the date from British to American using SET DATE command?
>>>>>>
>>>>>>For example, say you have a char column in a DBF like this:
>>>>>>14/10/2020
>>>>>>08/03/2012
>>>>>>16/2/2020
>>>>>>3/3/2010
>>>>>>all the above characters show the date in a British format. Note the above are not dates but char representation of a date.
>>>>>>Now I want to change them to American format (mm/dd/yyyy)
>>>>>>Can it be done without many SUBSTR()?
>>>>>>
>>>>>>TIA
>>>>>
>>>>>Yes, if you do SET DATE TO BRITISH, then use the CTOD() function you'll get the date values as you'd expect (assuming that the string you're passing to the CTOD() function are indeed formatted in dd/mm/yyyy format. You do have to be careful when changing setting like SET DATE -- it might cause existing code to break (if it's not coded to be independent of the SET DATE setting)
>>>>
>>>>I tested the use of CTOD() and then getting MONTH(), DATE(), YEAR() from the result. Then changing to SET DATE AMERICAN and creating a new date using
>>>>

>>>>dAmericanDate = Date(nYear, nMonth, nDay)
>>>>

>>>>So I will just create a simple PRG to scan all records and changing SET DATE from BRITISH to AMERICAN.
>>>>This is a one-time procedure; converting some data.
>>>>Thank you for your message.
>>>
>>>Yes, creating the date using the DATE() function and datetime values using DATETIME() would be independent of the SET DATE setting. Similarly using the strict format for date and datetime constants {^yyyy.mm.dd} and {^yyyy.mm.dd hh:mm:ss} would not be dependent on the SET DATE setting. Where you're apt to run into problem is if you're using CTOD() and CTOD(), or date and datetime values not in strict format {a.b.c} or {a.b.c d:e:f} -- these would be dependent of the SET DATE setting -- either at runtime or at compile-time. I added the warning simply because a lot of older xBASE code tended to break due to use of CTOD() that made it dependent on the SET DATE setting.
>>>
>>>I do remember having code like this in the procedure file (back in the dBASE III+ days):
>>>

>>>PROCEDURE MkDate
>>>    PARAMETERS nYear,nMonth,nDay, dRet
>>>    PRIVATE dChk
>>>
>>>    IF TYPE("nYear")<>"N" .OR. TYPE("nMonth")<>"N" .OR. TYPE("nDay")<>"N"
>>>        dRet = CTOD("")
>>>    ELSE
>>>        dChk = CTOD("1/2/3")
>>>        DO CASE
>>>            CASE MONTH(dChk)=2 .AND. DAY(dChk)=3     && ymd
>>>                dRet = CTOD(LTRIM(STR(nYear,2)) + "/" + LTRIM(STR(nMonth,2)) + "/" + LTRIM(STR(nDay,2)))
>>>            CASE DAY(dChk)=2 .AND. MONTH(dChk)=3     && ydm
>>>                dRet = CTOD(LTRIM(STR(nYear,2)) + "/" + LTRIM(STR(nDay,2)) + "/" + LTRIM(STR(nMonth,2)))
>>>            CASE MONTH(dChk)=1 .AND. DAY(dChk)=2     && mdy
>>>                dRet = CTOD(LTRIM(STR(nMonth,2)) + "/" + LTRIM(STR(nDay,2)) + "/" + LTRIM(STR(nYear,2)))
>>>            CASE MONTH(dChk)=1 .AND. DAY(dChk)=3     && myd
>>>                dRet = CTOD(LTRIM(STR(nMonth,2)) + "/" + LTRIM(STR(nYear,2)) + "/" + LTRIM(STR(nDay,2)))
>>>            CASE DAY(dChk)=1 .AND. MONTH(dChk)=2     && dmy
>>>                dRet = CTOD(LTRIM(STR(nDay,2)) + "/" + LTRIM(STR(nMonth,2)) + "/" + LTRIM(STR(nYear,2)))
>>>            CASE DAY(dChk)=1 .AND. MONTH(dChk)=3     && dym
>>>                dRet = CTOD(LTRIM(STR(nDay,2)) + "/" + LTRIM(STR(nYear,2)) + "/" + LTRIM(STR(nMonth,2)))
>>>        ENDCASE    
>>>    ENDIF
>>>    RETURN
>>>

>>
>>Thank you very much for the code.
>
>Note that the code provided above isn't needed anymore (nor would it be desirable -- it is an unnecessarily convoluted method to do something that could be done in a simpler, cleaner fashion) -- only needed it back in dBASE III+ because of various limitations:
>* DATE() function was limited to only returning correct date -- there wasn't a variant that allowed you to construct a date value w/o being dependent on the SET DATE __ configuration
>* using procedure called using DO ... WITH ... (the first three parameters are input parameters and fourth is the output parameter) because user-defined functions weren't available in dBASE III+
>* there wasn't a SET() function that allowed you to retrieve the current state of the SET ___ setting
>
>Other "coding horrors" of the day include:
>* heavy use of INKEY() loops to deal with password entry and menus
>* "pseudo-array" that relies on macro expansion to "index" into the array (e.g. use individual variables like AVAR01, AVAR02, AVAR03, etc. then use macro expansion to "index" this "array").

Thank you.