James Byrne writes:

> Well, we have been clients of HP and users of Image since 1984
>  and we standardized upon a six digit signed zoned decimal date
>  format in 1984.  Last New Years Day we converted all of our
>  dates everywhere to our new standard eight digit signed zoned
>  decimal date format.  It really was not that big a deal.

[snip]

>  We have bitten the bullet on the storage issue and and are now
>  set to handle dates until AD 9999 expires.  Many of the
>  proposals regarding Y2K rollovers seem only to be moving the
>  next event horizon out to 2049.  I don't see that that is much
>  of an improvement over what has gone on before.
>
>  Image had and has a perfectly good date format already.

Let me absolutely agree with Jim. Over the past several years, I've become
fairly adamant about not doing anything screwy with dates, most especially
with integer number counting schemes, simply to make life easier for the
people who have to use these databases.

If I disagree with Jim on any point, it would be that I would make the date
fields X8 rather than Z8. Although the bit patterns are exactly the same (if
the numbers are unsigned), there is no advantage in having the pattern be
interpreted as numeric, simply because the moduli of the various portions of
the number are  different [100 (century), 100 (year), 12 (month), 28-31
(day)], thus two dates obviously can't be subtracted from each other
directly.

However, people do constantly want to parse the dates so that they only look
for days falling in May of 97, or perhaps just May, regardless of year. That
can't be done in Z8 numeric format with most tools on the HP3000 -- but it
can easily be done with an X8 text field. That's a big difference for no
difference at all in bit patterns.

Secondly, if hours, minutes and seconds are important to your operation, I
also strongly recommend that time also be a concatenated part of the
time-date stamp (i.e., CCYYMMDDHHMMSS), not a separate field. Not only are
X14 (or X8) fields immediately sortable and easily parsible, such
concatenated fields avoid the curse of data independence that exists when
date and time are separate fields (that is, the problem of trying to find all
of the records that occurred since 10:00PM three nights ago and before 6:00AM
this morning). If date & time are a unit item, the query problem is simple.
It is a pain if they are not.

Wirt Atmar