Re: 2039 cutoff

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