Re: Two digit date window -- MIDRANGE-L

From how I understand it, the limit with the 2 year date limit is
on the input and checking.  There is just no way to store more than
100 values in 2 numeric digits.  So, if you insist on using a 2
year date for input (we do) then you must use a window.  

We use a window all the time.  When we write a check, we usually
write 06/15/01 as the date.  Everyone knows this is 2001 and not
1901 or 2101.  It is a natural window.

Now, in computers you want the users to only have to put in 2 digits,
so the system must use some type of window.  Obviously 1900 to 1999 
wouldn't work, as we're in 20xx already.  2000 to 2099 wouldn't work,
as we have some history dates to put in.

So, the system uses a window of, what was it?  1929 to 2028 ?  Your
concern is what is going to happen when you go past the 2028.  

You bring up a good point.  You have a date of 01/01/29 which is stored
as 1929-01-10 (*ISO).  IBM moves the window, and the program goes to 
retrieve this date.  Ooops.  It can't, obviously.  If it shows the date
as 01/01/29 you will think it's 2029.  Just as, currently, it is
impossible to show a 1901 date using MM/DD/YY.  If I say 01/01/01 you 
are naturally going to assume it's 2001-01-01.  

So, what is the solution?  Simple, if you are concerned about dates
being outside of the current window, whatever it happens to be at the 
time, then you can not use MDY.  Even if you didn't use IBM's dates, what
are you going to do?  How are you going to store a date of 1901-01-01
using MMDDYY?  It is impossible.

You have to use some form of 4 digit year, such as *ISO CCYY-MM-DD.  Or,
make sure you archive out the dates outside of the window from your
active database, which you would have to do anyway using numeric YYMMDD
formats.

The problem is going to crop up whether you use your own date routines,
or IBM date routines.  2 digit years are a shortcut, with built in 
problems that we have to either code around, maintain, or not use 2
digit years.

Me, I'll continue to use 2 digit years, use TEST(DE) on input and store.
For history dates we'll have to archive out the data when it becomes an
issue, which it may some day.  it's not going to be impossible to archive
those dates out even when we are past the date range.  Just because your
database description is specifying them as *MDY doesn't mean you can't
redefine them in your program as whatever you want, *ISO being my choice
for in-program date calculations.

Regards,

Jim Langston

Date: Mon, 18 Jun 2001 10:19:26 -0400
From: Jon.Paris@hal.it
Subject: Re: Two digit date window

 >> 1939 or 1927  or 28 and below go Boom too under  the 1940- 2039 theory

 >> All windows are only as stable  as  their internal pivot year relates
to the dates received for processing. YES/NO?

Yes - but ..........  Maybe I'm not saying things very clearly.  Let me try
it this way and then I'll get on with real work <g>

"Real" dates on the database don't really have a pivot year - they are
stored as a day count - not as year digits subject to pivot interpretation.
The value stored on DASD will be the same for Jan 1st 1940 regardless of
whether DATFMT is *MDY or *ISO.

Let's say I have designed a database.  It includes a "real" type L date
field, because I was told it would guarantee that only valid dates would
ever be stored.  I chose DATFMT(*MDY) as the format for that date because
that is what my users like and because the dates will _never_ go outside
the range 1950 - 2020.

This works well for a while until one day IBM decides to change the date
window.  Instead of 1940 - 2039 the window is moved ahead 20 years to (say)
1960 - 2059.   The first time that my application reads a record with a
date in the 1940 - 1959 range it will blow up.  Not on every record - just
anywhere the stored binary day count equates to a date outside the new
range.  Not only that it will do so in a way that gives me no way of
effectively handling the error, since it will occur while the buffer is
being unpacked.

In order to resolve this I would have to do a CHGPF with new DDS that
changes the *MDY format to (say) *USA (I am assuming that this works -
can't think why it shouldn't - otherwise I have to copy the file).  But
then I have to modify all my programs to handle the 4 digit year.  That is
not acceptable to me.  I used "real" dates for reasons of integrity - a
change in the window broke that rule.  I now have dates stored that are
outside the window, and I have no choice but to change my programs to
accept 4 digit years.

Jon Paris
Jon.Paris@e400.com

www.e400.com - A new wave of iSeries and AS/400 Education
+---
| 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
+---