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
midrange.com
