Re: AS400 Date Window For *MDY

["John Taylor" <john.taylor@xxxxxxxxxxxxxxx>]

Hi Jim,

> If they don't change the range, then date fields will become worthless in
> 2041.  What are they going to do then, make a *newdate type?  IBM would
> have to change the date to make it usable, and what they would most likely
> do would just be to move the low and high end up a bit, say by 20 years.
> So instead of 1941 to 2040 it would become 1961 to 2060.  I think the real
> limitation is only how a two digit date is expressed, not in how it is
stored,

Once again, I agree. The internal date storage is fine. The problem is, how
exactly is IBM going to allow us to express 01/01/2040 in  *MDY, *YMD, and
*DMY formats? Is the window going to slide like you've suggested? If it is,
why don't they just say so? Instead, all of the available documentation
suggests that the opposite is true.

This is not a problem that will only appear 40 years from now. In 10 years
time, a 30 year mortgage amortization schedule may be affected.

> though, so our data shouldn't change at all.  What are you doing in your
own
>programs with 2 digit date field entry?

Within our database, most dates are stored in an 8 byte character field in
ISO format - without the separators. Wherever backward compatibility isn't
an issue, I have begun to use true date fields in the default ISO format.

Most of our displays and reports show a six digit date in MDY. This is
normally implemented as a zoned 6 byte field with edit code "Y".  The
subroutine that converts the date to MDY simply ignores the century. This is
what I assumed OS/400 would do when I began to use the date data type in any
new reports. It was the earlier thread about it being a fixed window that
initially compelled me to wonder what would happen.

For input, we use the same six digit MDY numeric field and convert that to
ISO before storing it in the database. The conversion routine uses a sliding
window technique. I don't use the date data type for input because of the
annoying way that it's supported in DDS - no null or blank dates allowed.

> I think you will have a lot more to change come 2040 if you do it
yourself, then
> if you let the OS handle it.

On the contrary. As I explained, our output fields are numeric 6 digit
fields. The routine that converts from 8 to 6 digit formats drops the
century, so both 1940-01-01 and 2040-01-01 will be displayed as 01/01/00. No
exception is raised. OS/400 generates an exception, and that's what will
cause the program to fail.


John.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---