Agreed,
I had figured it out about ten minutes ago....we have a program that
calculates due dates based upon a 8,0 date passed in.....it will return
an 8,0 iso, usa, mdy date back.....if you pass in a 2040 date it will
bomb....in this particular case it was not. The reason was they are
entering the date as a six digit which is converted to a date format so a
052240 gets converted to a 05/22/1940 which is valid and thus does not
generate an error.....
I KNOW I KNOW I KNOW we should be using 8 digit dates at the very least
and preferrably a complete usa format.....but I can only control so
much....we are getting there it is just taking a while to get the user
base on board.....and that is the push back. They think that entering
052208 takes less time than 05222008 which is true but who the hell is
counting micros when it comes to data entry....but that is the thinking.
From:
CRPence <CRPbottle@xxxxxxxxx>
To:
rpg400-l@xxxxxxxxxxxx
Date:
05/29/2008 04:13 PM
Subject:
Re: Dates greater than 2039
The date 15-Dec-2040 represented in *ISO is 2040-12-15 and
represented in *YMD would be 40/12/15. However that same *YMD value of
40/12/15 is _actually_ understood to be the *ISO 1940-12-15, and there
would be no error generated for using that value; except perhaps
incorrect output. What this suggests, is that although there is no
support for a six digit year representing 2040 [and beyond], the six
digit date can still be validly interpreted without error even if it is
/incorrect/ for the wrong century. That may be what is the issue here.?
Doug Palme wrote:
It used to be that any date greater than 2039 would cause an
error with a six digit date data type.....did IBM fix that?
Because it no longer seems to be a problem......
midrange.com
