Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Change date from British to American?
Message
From
08/07/2021 18:56:06
 
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
01681748
Message ID:
01681752
Views:
38
>>>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
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform