On Wed, 6 Sep 1995 Peter Volk <[log in to unmask]> said:


> Many of the objects in the collection have imprecise dates attached,
giving
>only month and year, and often only year. [...]

Most databases that offer a "date" field use an algorithm that is
incompatible with the needs of recording historical dates.  Some databases
allow the user to break the rules, but even then the system may stop
functioning for unusual dates.  The database I use most often cannot
understand a date earlier than 1600.

Consequently, I create my own date fields by separating day, month and year
into three separate fields and using programing to govern their
relationship (months 4,6,9,11 can have a maximum of 30 days) .  By
convention, I allow a "0" entry to signify an unknown (though it screws up
any kind of date arithmatic I may wish to perform).  This way, when
recombined, 7/0/1995 will signify July 1995 and 0/0/1995 signifies some
time in 1995.

In reality, any date should be recorded with a field that explains the
nature of the date (circa, no earlier than, etc.), and, depending upon the
type of collection, how that date was determined (documented, attributed).
Some collections will require two date fields, one for the earliest date of
a range and another for the latest, some will require four or more...

The above is just a simplified example of some of the complexities inherent
to entering dates in computer databases.  Several of the museum database
systems available commercially have tackled this problem with great success
and sophistication.  I can send you (and other museum-l readers) a copy of
a set of codes I developed that may be incorporated into simple database
systems that cover a broad range of date recording situations.
--
______________________________________

Robert A. Baron
Museum Computer Consultant
P.O. Box 93, Larchmont, NY 10538
[log in to unmask]