Re: legacy date hell

You can not leave a "date" field blank. To signal a missing date there is
NULL.

On Wed, Aug 26, 2020 at 3:18 PM x y <xy6581@xxxxxxxxx> wrote:

My approach--which is easy with SQL--is to leave the
maximum/cancel/expiration date blank if it's not known. IMO using an
actual date, whether valid or not, is more technical debt, misleading to
the uninformed user, and will likely bite you at the worst possible time.

Instead, you can do something like this...
WHERE (:trandate BETWEEN effdate AND candate
OR :trandate >= effdate AND '0001-01-01' = candate)

Or, if you want to get fancy, use a stored procedure:
WHERE sps030(:trandate,effdate,candate) = '1' --'1' means trandate is
between effective and cancel dates or is >= effective date and no cancel
date has been entered

-Xavier


On Tue, Aug 25, 2020 at 6:19 AM Jay Vaughn <jeffersonvaughn@xxxxxxxxx>
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
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com