To say that because many people do not use date fields properly we should
not use date fields is an interesting arguments.  Date fields should be used
rather than general data fields for acquisition date, valuation date,
movement date, conservation date, etc.  If the museum does not know the day,
month and year for these events then there may be other problems.  Using
date fields allows for easier retrieval of data via a specified time period.

On the other hand the date an object was created may placed in a general
data field if your database does not allow for creation of a year only
format.

Most windows and mac databases developed in the past five years have the
ability to record year as 1997 not just 97.

-----Original Message-----
From: Orycteropus afer <[log in to unmask]>
Newsgroups: bit.listserv.museum-l
To: [log in to unmask] <[log in to unmask]>
Date: Wednesday, July 16, 1997 1:29 AM
Subject: dates 2000 or otherwise in automated systems



Further on the topic of dates in automated systems:

In addition to the considerations raised recently regarding accession
numbers and the year 2000, dates in general should be of concern to
automated system users.  Far too many automated systems define the fields
used to record dates (acquisition dates, dates of manufacture, conservation
dates, movement dates, etc.) as what is called a "date" type field internal
to the database management system.

This is almost always a BIG mistake.  While date type fields may on the
surface appear flexible (particularly during demonstrations prior to
purchase of the system) in that date type fields may be displayed in a
variety of formats -- CCYY-MM-DD or DD-MM-CCYY or DD-MM-YY or DD MMM YYYY --
and therefore appear to be able to accommodate US, Australian, Canadian, or
UK preferences, in fact they are extremely inflexible.  This is because a
huge percentage of dates recorded in manual documents (as we all know) are
not complete dates and lack days or days and months.

In most database management systems, a date type field MUST have a day and
month value.  Entering no values or zeroes are generally not acceptable.
Thus, the museum is forced to enter spurious data in order to be able to
enter any information into these fields.  The spurious data generally takes
the form of January 1.  Anyone who has ever reviewed the data in most
existing museum automation systems will see a plethora of items acquired on
January 1, items moved on January 1, etc.   This is not good and jeopardizes
the integrity of the database.

The more sophisticated way to handle dates in an automated system is to
define fields that will carry date information as "character" type fields
and then to create a mask that requires that data entered into these fields
follows a certain pattern but a pattern that doesn't have to have a day or
day and month component.  While this approach may affect the ability to
switch between different date formats, it safeguards the integrity of your
data.

There are a few places in museum automation systems where date type fields
are appropriate such as in those fields used to automatically record when a
record was created or updated.   In general, though, date type fields are
not a good solution for recording the kinds of dates found in museum
documentation.