Debbie Blumenthal <[log in to unmask]> wrote:

>James Overman <[log in to unmask]>
>after
>> David Greer ([log in to unmask]) wrote:
>> : <<big snip>>
>> : probably default the cut-off date to 50 (i.e., 500101 will be assumed
>> : to be January 1,2050, but January 1, 490101 will be interpreted as
>> : 1949).  We have enough feedback from our customers to know that the
>>
>> Don't you want 490101 to be 2049 and 500101 to 1950??  Thus 000101 would be
>> 2000 !!
>
>This sounds a little like my former boss's "quick and dirty" fix.
>The whole "Year 2000" situation is much more serious than that.  For
>example, you couldn't possibly use this method on a stored Birth Date
>field (just counted over 500 students-past and present- born prior to
>1950, and then stopped counting...)  So, you'd end up with different
>logic to "control" different types of date fields, and likely more
>errors within the data.
>
>Isn't it better and safer to convert the data to hold the century and
>be done with it?  Yes, there's still a lot of work involved, but when
>it's done, it's done.  You won't have the ugly date problem coming
>back to slap you in the face on a regular basis.

I agree with Debbie's "once and for all" approach.

As an example, Adager (when converting dates from an old format to a new
format) supports ONLY destination formats that are capable of holding a
4-digit year.

Specifically, when converting dates with Adager:

        - You can specify a number ("between 1 and 99") as the cutoff (to be
          applied to the SOURCE value), if you, indeed, are using a cutoff.
          Our default is "no cutoff".  Notice that the specification of such
          a cutoff value is a one-time occurrence with Adager, because you
          only need to supply it when you convert your dates.  Once you have
          CONVERTED your date values, they will be, by definition, in a 4-digit
          year format (which does not require a cutoff trigger).

        - You can "convert the data to hold the century and be done with it".
          For instance, if your data is in yymmdd (or dd/mm/yy, or any of such
          combinations and permutations), you can easily convert it to
          yyyymmdd (or dd/mm/yyyy, or whatever).  Notice that the source
          dates have only a 2-digit year value and the destination dates have
          a 4-digit year value.  This is the whole point :-)

The bottom line is that, when you use Suprtool to cruise through your
(nicely converted) data entries, it will be able to collate CORRECTLY,
because 2050 (or 2098) do, indeed, collate AFTER 1950 or 1998.

Why force Suprtool to go through unnecessary gymnastics to try to interpret
what is, essentially, TRICKY information?  Debbie is proposing a clean-up
process to get rid of the tricky part ("convert the data to hold the
century").  This has to be done sooner or later.  Debbie recommends doing
it sooner.


Just in time (no Java pun intended),

 _______________
|               |
|               |
|            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.
|               |
|_______________|