Re: legacy date hell

[Brian Parkins <goodprophet.bp@xxxxxxxxx>]

Correct me if I am wrong. You are holding dates as 8-digit numeric 
values (8S0) in the table, but displaying them as 6-digits (3 x separate 
fields) on the 5250 display?

The User wishes to specify a future date value (i.e. 31st December 9999) 
so the record will never "expire"?

How about allowing 99 99 99 on input (as distinct from 21 31 99). This 
will identify as "never expire". Modify the table to denote the 8S0 
field as null-capable. If 99 99 99 is entered, set the field to null. 
(More coding necessary to handle null-capable fields.)

Alternatively, could you introduce an additional (century?) flag-field 
to denote "never expire"? (Smart use of views / logicals would minimise 
the database impact but still need some coding changes.)

Just some suggestions. (Personally, I would go for the refactor option 
AND implement proper dates fields in the table(s) instead of 8S0.)

HTH.
Brian.

On 25/08/2020 14:18, 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