|
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
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
