×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 28-Nov-2011 09:02 , rob@xxxxxxxxx wrote:
If one tries to convert 2040-01-31 to MMDDYY it aborts.
Documented here at
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/db2/rbafzch2date.htm
and elsewhere.
Is there any talk about sliding that window?
No clue. I would expect possibly, enablement via something like the
DATTIM() feature for COBOL to [re]define the 100-year window to be
used.? Sure would be interesting to know what the Work Management would
do for the resolution of a preference to the *JOB [system value, user,
job description, ??] for handling of the 2-digit year formats, as paired
with [or instead just] the command definition PARM TYPE(*DATE).
Since we've already hit a hiccup are some people considering
dropping using built in techniques to convert from 8 to 6 digit date
fields and use custom code?
If I were to stray from *ISO [or another standard 4-digit year
format] in order to effect 2-digit year representation of dates that
might fall outside the defined 100-year window from 1940-01-01 to
2039-12-31, I would just use an expression to pare the result of a
4-digit year format using either CHAR(real_date_type,ISO) or
CHAR(real_date_type,EUR) to effect a 2-digit year presentation.
For example, any of:
insert( char(current date, EUR) , 7, 2, '') /* 28.11.11 */
substr( char(current date, ISO) , 3, 8) /* 11-11-28 */
right( char(current date, ISO) , 8) /* 11-11-28 */
varchar_format(current timestamp,'MM/DD/YY') /* or to_char();
note: untested; I am only guessing that particular scalar has no
concern for the ambiguity of YY since it is "formatting" rather than
"casting" */
Regards, Chuck
midrange.com
