date problem.

[Richard Kreiss]

Jay,

In answer to your reply, the date fields are (10,mdyy/).  The issue is that
when pfcmark is set to 20, and the operator type in an expiration date of
031520, filepro expands the date to 03/15/1920.  This would be fine for a
birthday but not an expiration date of 03/05/2020.  I have changed it to
pfcmark="30" to accommodate the expiration dates

Since my client has members who are over 70 years old and deal with credit
cards which expire in 2020 or later, the setting of pfcmark creates a
problem.

At this point my client is having the birthday information entered with all
10 characters as he doesn't want to pay for two easy solutions to the
problem.

Since most of the member information is imported, I could set pfcmark=20 for
the import routines which would insure the proper birthday values.  The some
simple programming san be added to insure, if the date is changed, it still
falls in the proper date range.

This is an issue that insurance companies most have as they have clients who
were born prior to 1930 and have policies which are paid automatically to a
credit card when the premium is due.  They need to be able to handle this
date problem also

My question was how others on the list may have handled this problem if it
arose with a client or their own business.

As an aside, in 1992 I had already built in date programming to handle Y2K
problem.  This was many years before filePro add pfcmark which basically
built in what my programming was doing.  One client is still using that
programming without a problem.  


Richard Kreiss
GCC Consulting

Office: 410-653-2813



> -----Original Message-----
> From: Filepro-list [mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Jay Ashworth
> Sent: Monday, February 16, 2015 10:46 PM
> To: FilePro Mailing List
> Subject: Re: date problem.
> 
> ----- Original Message -----
> > From: "Richard Kreiss" <rkreiss at gccconsulting.net>
> 
> > One of my client's emailed me the other day about a date problem.
> > Pfcmark = 20
> >
> > Here is the problem, they have member records with birthdays as early
> > as the 1920's. However, they also h handle credit cards with
> > expiration dates after 2020. This is creating an interesting problem
> > in insuring that the dates are correct.
> >
> > I realize that I can write some date check logic for wither date.
> > Since the doesn't change, It would be easiest to check the birthdate
> > on import by setting pfcmark as part of the import routine.
> >
> > I am just wondering how one of you might handle this type of issue.
> 
> I'm aware that this answer will sound a little snotty, but I'm too tired
to care.  :-
> }
> 
> "Do the work you should have done 17 years ago: convert all date fields to
> MDYY/, and make sure all intermediate dummies are big enough and that all
> code that touches them makes no intemperate assumptions about their type."
> 
> Why do I know that?
> 
> Cause I did it all, 17 years ago.  For about 20 clients.
> 
> Those were halcyon days... :-)
> 
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink
jra at baylink.com
> Designer                     The Things I Think                       RFC
2100
> Ashworth & Associates       http://www.bcp38.info          2000 Land Rover
DII
> St Petersburg FL USA      BCP38: Ask For It By Name!           +1 727 647
1274
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list