Re: Date conversion from m/d/ccyy format

On 23-Mar-2012 15:53 , Barbara Morris wrote:

On 2012/3/23 11:28 AM, John Yeung wrote:

For the *USA format, %DATE handles single digits for both month
and day.

That's not a documented feature. RPG officially requires that the
month and day each have two digits, with leading zeros if necessary.

I'd assume it wasn't supported, and massage the character value so
that it was in mm/dd/yyyy form, and then use %DATE.
<<SNIP>>

FWiW: Actually documented not to be supported:
*i "Leading and trailing zeros are required for all date data." i*

_Date Data Type_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/books_web/c0925086187.htm#HDRDDATE
"
Date fields have a predetermined size and format. They can be defined on the definition specification. Leading and trailing zeros are required for all date data.

Date constants or variables used in comparisons or assignments do not have to be in the same format or use the same separators. ...
"

Perhaps an observation that the *USA standard format may enable "single digits for both month and day", might apply to all of *ISO, *USA, *EUR, and *JIS [same as *ISO]. Perhaps as a side effect of the lower level implementations for the date data type, the respective "Minimum Input Length" of eight for each, for the Data Definitional Attribute List [DDAT]; albeit only the "SAA timestamp" suggests that the "Leading zeros may be omitted from the month, day, and hour part of the timestamp"?

I was unable to get any examples to work, even for *USA; RNQ0112 "Date, Time or Timestamp value is not valid" at run-time and RNF7510 "The operand '7/4/1999' is too small to contain a complete *USA/ date.
_Date, Time, and Timestamps_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzatk/MINDTCON.htm#HDRDDAT
" ...
The following table describes the _format code_ The formats are used to define the representation or interpretation of data across the MI. They also imply the length of the data, some of the minimum lengths can only be utilized when a null date or time separator has been specified.
...
"

However according to the SQL, the same lacking "leading zeroes" is acceptable across all of the /standard formats/ which all have an implied separator and 8-byte minimum input length per the DDAT. Thus the SQL should be able to handle them.

I was able to get all of my examples to work using the SQL DATE scalar, for all of those standard [not the job] formats:
_String representations of datetime values_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/db2/rbafzmstch2data.htm#dtstrng
"Leading zeros can be omitted from the month and day portions when using the IBM® SQL standard formats. Each IBM SQL standard format is identified by name and includes an associated abbreviation (for use by the CHAR function)."

Regards, Chuck