>Date:    Thu, 17 Jul 1997 10:32:11 -0400
>From:    Liz Waters Heinrichs <[log in to unmask]>
>Subject: Re:
>
>> I'll second the Aardvark's suggestions and add that if the information in
>> the character field is entered as numerals in the order of year, month,
>and
>> day (preferably with some sort of standard separators to insure ease of
>> reading), easy sorting in chronologic order is possible.
>>
>> Art Harris
>
>
>However, I also find it useful to have a field in a database which is the
>year in full.  Databases I have constructed have not been for museum
>accessions, rather elaborate finding aids, but MS database programs don't
>appear to have any way of dating prior to 1900 and sometimes I need to be
>able to date things in the C19th!
>Years in full, with the field as a number rather than a date, appear to
>work well in conjunction with a separate date field - records can then be
>sorted by year and then date resulting in good date order.
>
>Elizabeth Waters Heinrichs
>HISTORY MATTERS
>[log in to unmask]
>
When designing a museum database, each field should be considered from the
separate viewpoints of data entry, data updating, querying, sorting,
displaying, and reporting.  The individual needs of each of these elements
must be balanced in the way the data field is structured and in the
formatting conventions adopted to record the data.

In the case of dates, particularly the date made or geological date, an
optimal approach is often the inclusion of a "display" date field with an
associated set of "numerical" date fields to record the quantification of
the earliest and latest dates this "display" date represents.  Think of the
"display" version as what you want to see in a catalogue or on a gallery
label such as "probably early to mid 10th century" and the "numerical"
version as what you need to satisfy your needs for searching the data.  Some
date fields may rarely be searched and are just along for the ride.  These
probably don't need to have display and numerical versions.  Others, like
the date made or the date associated probably do if you're really going to
use the data in interesting ways.

Other issues (in case anyone is interested) regarding dates are the
differentiation of date made versus associated dates, maintaining running
histories of previous dates assigned to an item (rather than just trashing
the old date when a new one is assigned), having a mechanism in your
database that automatically knows that when you search for items made in
1950, you get items with dates made recorded as "mid 20th century," "1950s,"
or "1940-1960."   And, wouldn't it be fun to also be able to carry in the
database metadata on what was going on in 1950 in general?  This latter
concept when applied imaginatively could potentially convert megabytes of
data into extraordinarily compelling interlinked information.

There's actually an interesting discussion that relates to this by Kevin
Donovan at