MUSEUM-L Archives

Museum discussion list

MUSEUM-L@HOME.EASE.LSOFT.COM

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Orycteropus afer <[log in to unmask]>
Reply To:
Museum discussion list <[log in to unmask]>
Date:
Wed, 16 Jul 1997 00:29:14 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (41 lines)
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.

ATOM RSS1 RSS2