Re: legacy date hell

[Sam_L <lennon_s_j@xxxxxxxxxxx>]

Insufficient data to make a recommendation. But some thoughts...

Have you determined what "never expires" means?  Is there a program 
somewhere that sets an "expired" flag based on looking at this date? If 
so, then tweak this program to treat 12/31/2039 specially.  If the field 
is looked at all over the place to determine if the record is expired, 
well then that's a different situation.  Maybe you want to introduce an 
expired flag, and stop looking at the date, though possibly lots of 
changes needed.

Are there records with expired dates before 2000?  Are they useful? 
Could they be purged and would that help?

How far ahead of the current date can a real expired date be?  Let's say 
it is 5 years.  Then the 2039 solution becomes unworkable 2034. Makes 
sure the Biz understands.

As long as the Biz intends to rely on mm/dd/yy dates on screens & 
reports, they are tied into the IBM imposed 2039 limitation. So I don't 
see a way out of that, unless IBM is committed to changing the window in 
the future, which looks unlikely to me.

Fun, fun.

Sam





On 8/25/2020 9:18 AM, Jay Vaughn wrote:
> So we have an input date on the screen as 3 separate fields... mm dd yy
>
> Biz wants the ability to put a "max" date of 12/31/9999 in so that this
> record never expires.
>
> I guess they didn't review the 2 digit year on the screen first... because
> if you put 99 in then when it comes time to store that input into the table
> where the date is 8s0, then it will think it is 1999.
>
> And if we do store the date in the table as 12/31/9999, whenever any other
> pgm tries to convert from *ISO to *MDY, the pgm will blow up, because 9999
> is not a valid date for *MDY.
>
> So the way I see it the options are, train the user to input 39 into the
> screen yy for the max date which is the least invasive approach (and will
> create a new y2k scenario).  OR  expand screen date year to yyyy and
> refactor any and all pgms that convert this 8s0 date from *MDY to *ISO to
> handle the 9999 stored year correctly.
>
> Pretty sure they will want to go with the 39 approach as they "claim" the
> system will be decommissioned in a couple years (which I've heard that a
> million times before).
>
> Any other suggestions I am overlooking?
>
>
> tia
>
> Jay