RE: L-date fields -Reply

[David Morris <dmorris@xxxxxxxxxxxxx>]

>>> Scott Johnson <sjohnson@highsmith.com> 09/12 6:55 am >>>
>Bob,

>I have to ask the question that if we are not going to ask/demand 4 digit
years from the user how are we going to know for sure what century they
are talking about???   Programs cannot read minds.....

>Sure the programmer can do some fancy  programming to default it to 
some century when the year is less than some year, and some other 
century when greater than some year. BUT then that code would have 
to be 'fixed' in a few years.  We have some of this wonderful code in some
of our programs now.  And I personally don't like it. It is a band-aid.

>Also, the programmer code write some code that defaults to the current
century when on a 2 digit year is entered by the user.  Which I would
guess is happening in that program you saw..  But I feel this would open 
the database up to A LOT of key errors and bad data.  The user would
get into the habit of always just typing 2 digit years.  A customer will
come along who is born on 09/02/1898.  The user in all their habits
enters 090298.  Does not recheck the field when it gets resolved to
09/02/1998.  And the customer becomes not born yet in the database.

>--  Just my Two Cents Worth
------------------------------------------------------
>Scott P. Johnson  sjohnson@highsmith.com

A well thought out date expansion routine can enhance the accuracy of your
data.  One could argue that the user puts less thought into a single entry than
the programmer puts into editing the entry.   Many times I have written a
check in January for the prior year.  A well thought out date routine can avoid
such problems.  For example, when a program prompts for a closing date,
run date, check date, etc. if the user just enters the month and day (which can
in many cases be defaulted) there will be less chance the program will infer
an incorrect year.

We use a few standard procedures to parse all of our dates.  They have been
tested through thousands of entries and can be tuned as required with very
little impact on the programs that use them.  If you move your edits to a single
place, include reasonability (warning) checking, and error checking, you
should have little to worry about.

Another two cents.

David Morris                      
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---