RE: L-date fields

[Glenn Ericson <Glenn-Ericson@xxxxxxx>]

At 03:56 PM 9/13/97 +0000, you wrote:
>Wouldn't a d-o-b field be considered "strictly necessary" for a 4-digit
>year on the screen?  as well as any fields relating to property deeds and
>transfers, historical references, obvious on-screen sorting fields and
>filters, and query usage?  It's reasonable to expect a user to understand
>the appearance of 4-digit years in those cases.  While most dates will
>easily be contained in the 100-year window we now have available, if there
>is any doubt about a field then it should have 4-digit displays on the
>screen.
>
>on 09/13/97 at 07:29 AM, "Kahn, David" <KAHN@tengizchevroil.com> said:
>
>
A program should not accept a future DOB under any circumstances. The
>
program should be able to calculate the reasonable window for any
>
particular date and force confirmation of the defaulted century whenever
>
there is more than one possible solution. I don't think it's reasonable
>
to expect users to key the century part of the date when it's not
>
strictly necessary.
>
>
Dave Kahn
Booth 
It is  possible to  have 2 digits on the screen or report and 4 in the
database. Here you  window the input/output with some sort of intelligent
date routines.

The intelligence part comes from  other information displayed near and
around  the date on the same  screen or line.

This requires you know your data  very very well and there is little chance
of  change ( hum) in business rules.  Extreme caution is the watch word.
If it works  you do not have to worry about  reworking all those screen &
printer specifications & possible overlays in data.

Now the  4 digit  database will save your butt with sequencing problems,
Query, EASY, client server and  other inter system date trades.

There are standard date routines which can handle  or provide dual dates
and more.  I'll not mention products on the list.  Such routines also have
value in  building the  new 4{YYY} database files and moving the data
over... and more.  That is a part of their function beyond the API levels



Glenn
___________________________________________________
Glenn Ericson,          Phoenix Consulting                      
P O Box 701164   East Elmhurst NY 11370-3164 USA                            
Ph. 718 898 9805         Fx. 718 446 1150
AS/400 & Year 2000- - Solutions Specialists
 © 1997copyright,  all rights reserved
____________________________________________________


 
+---
| 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
+---