Fred White and I are polishing up the final details of Adager's
contribution to the year-2000 challenge and we need your collective help
regarding a thorny issue.
 
"Legal" dates are no problem at all.  We can surgically attach (no pun
intended) the century part to almost any date format in existence (with the
appropriate change in item definition, if necessary, including items that
specify search fields and require the rehashing of master datasets).  All
of these technical issues are difficult but mathematically solvable.
 
Ironically, our biggest PHILOSOPHICAL and managerial problem is what to do
with ILLEGAL dates whose semantics involve things OTHER THAN DATES.  Let me
give you a specific example.
 
Take an X6 item with DATE information in the YYMMDD format (today's date --
July 6, 1996 -- is 960706).  It's a snap to convert it to an X8 item with
the CCYYMMDD format (today's date -- July 6, 1996 -- is 19960706).  Some
applications, though, have overloaded this item so that in some datasets a
field value of 000000 means "invoice not yet paid", a value of 999999 means
"invoice cancelled", a value of 123456 means "invoice will be paid in
installments", or whatever, depending on the fancy of the application's
designer(s).
 
What do YOU say?
 
Should we flag these values as "illegal" and convert them to 19991232 (or
some such impossible and arbitrary date)?  The consequences are horrible.
For instance, different master-search-field values would collapse into one
value and dangling orphan detail chains would result.  The date-converting
procedures would "feel good", though, because they would not have
contaminated themselves with non-DATE values and they would have washed
their hands, perhaps with YOUR blood :-)
 
Should we just attach the century to these values (000000 -> 19000000)?
Should we just "expand" these values (000000 -> 00000000)?  Should we just
provide trailing or leading blanks for these values (000000 -> bb000000 or
000000bb)?  In all of these cases, you would have to change the tests in
your applications anyway.
 
Hopefully, this small tasting will give you an idea of the flavors to come.
I just did not want to totally ruin your appetite :-)
 
Yes, overloading is horrible.  But people do it all the time.  We don't
want to tell you what to do (you already have enough of that).  We just
want to help you do the thing that makes the most sense to you, within your
application's context.
 
So, please tell us about your special overloaded-DATE cases and how you
would like us to handle them.
 
A message to HP3000-L is good but a direct message to me is better.
 
Thank you,
 
+---------------+
|               |
|            r  |  Alfredo                     [log in to unmask]
|          e    |                           http://www.adager.com
|        g      |  F. Alfredo Rego               Tel 208 726-9100
|      a        |  Manager, Theoretical Group    Fax 208 726-2822
|    d          |  Adager Corporation
|  A            |  Sun Valley, Idaho 83353-3000            U.S.A.
|               |
+---------------+