RE: L-date fields -- MIDRANGE-L

FIXED windows should NEVER be used because the code will have to be modified
again sometime in the future.  I have no problem with floating windows, i.e.
based on UYEAR, provided the date in question is not a birth date and
providing you will never have more than 100 years of data on your system.
(While you might not care about orders which are 101 years old, you may care
about title searches beyond 100 years.)

IBM's 1940-2039 restriction on date date types is beyond comprehension.  I
just hope I am alive in the year 2039 to see how IBM explains why some
people will have to go through a Year 2000 conversion a SECOND time. 

Dave Kahn > and Scott Johnson >> wrote:
>
>>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.
>
>The code can be a bit more subtle than that. A reasonable window for any
>particular date can be determined based on the current date, and the
>code can be written so that the window moves with the current date. I
>agree with you, however, that the current < 40 = 21st century 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..
>
>Defaulting to the current century will not do. If today you see a DOB of
>1/1/98 then it might be reasonable to assume that it means 1898, but if
>you see it in a few months time it could represent the DOB of either a
>centenarian or a neonate.
>
>>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.
>
>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 - TCO, Tengiz, Kazakstan
>=========
>
>e-mail:  kahn@tengizchevroil.com    (until September 30th)
>         dkahn@cix.compulink.co.uk  (from  October 1st)
>+---
>| 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
>+---
>
>

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