topic Re: Date conversion using WRITE statement in Application Development and Automation Discussions

Date conversion using WRITE statement

kjyothiraditya — Mon, 03 Apr 2017 10:53:47 GMT

Hi Experts,

In a report I need to convert date (YYYYMMDD) to another format DD/MM/YY using WRITE statement as below. For one of the record which has value 20170403 it is converting wrongly as 17/04/03. the conversion is done using as below.

WRITE lv_fkdat to lv_date DD/MM/YY.

The type of lv_date is declared as char8.

However for other records it is working fine. If I change the value in debugger, it is working correctly.

Thanks and Regards,

Aditya

Re: Date conversion using WRITE statement

Former Member — Mon, 03 Apr 2017 11:52:13 GMT

The Write statement will generally get things right (!) if the data has a domain that has a conversion exit attached to it and it's the type of lv_fkdat that you need to worry about.

If lv_fkdat has a dats type (sy-datum or whatever) then writing that will result in the correct format for the user. Otherwise have a look at the date convert function modules such as CONVERT_DATE_TO_EXTERNAL.

Rich

Re: Date conversion using WRITE statement

retired_member — Mon, 03 Apr 2017 11:52:23 GMT

The separators and the sequence depend on the formatting setting of the language environment that is predefined by fixed values in the user master record and can be influenced by SET COUNTRY. Is your result user dependend or is there any SET COUNTRY before WRITE TO?

Re: Date conversion using WRITE statement

kjyothiraditya — Mon, 03 Apr 2017 16:32:53 GMT

Hi Horst,

Thanks for your reply, but we are not using any user-specific setting or country speciifc formatting in the report.

It happened only with this test case. However for another date, if I changed the value, it is considering the WRITE statement format.

Once again thanks for your time.

Regards,

Aditya

Re: Date conversion using WRITE statement

kjyothiraditya — Mon, 03 Apr 2017 16:32:59 GMT

Hi Richard,

Thanks for your answer. Does it mean that the conversion routine takes precedence over the WRITE statement ?

It happened only with this test case. However for another date, if I changed the value, it is considering the WRITE statement format. Request you to help me understand this ambiguity.

Once again thanks foryour time.

Thanks and Regards,

Aditya

Re: Date conversion using WRITE statement

retired_member — Mon, 03 Apr 2017 16:36:21 GMT

"Thanks for your reply, but we are not using any user-specific setting or country speciifc formatting in the report."

Of course you do. Any WRITE statement using these date options does it - if not overridden by a conversion routine as Rich pointed out.

Re: Date conversion using WRITE statement

Former Member — Tue, 04 Apr 2017 03:54:32 GMT

I'm not sure in your program contain any Set country or be effected from user profile.

Why don't you try to split to day month and year then combine the format that your want.

day = lv_from_date +6(2).

month = lv_from_date+4(2).

year = lv_from_date+2(2).

Thank,

Re: Date conversion using WRITE statement

Sandra_Rossi — Tue, 04 Apr 2017 05:01:34 GMT

Agreed - KISS principle: if one doesn't master ABAP, just use:

lv_date = |{ lv_fkdat+6(2) }/{ lv_fkdat+4(2) }/{ lv_fkdat+2(2) }|. " CCYYMMDD -> DD/MM/YY

Re: Date conversion using WRITE statement

matt — Tue, 04 Apr 2017 08:08:44 GMT

Use substring instead of +x(y)?

Re: Date conversion using WRITE statement

Sandra_Rossi — Tue, 04 Apr 2017 11:07:17 GMT

+() is obsolete ? 🙂

Re: Date conversion using WRITE statement

matt — Tue, 04 Apr 2017 11:43:45 GMT

Substring is more obvious. I like obvious code.

Re: Date conversion using WRITE statement

Former Member — Tue, 04 Apr 2017 12:26:04 GMT

The Write statement uses the conversion exit if the data element is specified with the correct domain.

Rich

Re: Date conversion using WRITE statement

Former Member — Tue, 04 Apr 2017 12:27:04 GMT

I prefer a structure - move your string to the struc and then read the components, or move your data to the components and read the string.