Date and Time Use Cases

Statens Museum fur Kunst

Date and Time Requirements

1. Date entry in our current system generates Display strings in a predictable way.

In CollectionSpace, however, everything must be manually entered.

Action: Create a date display entry module to add on to CollectionSpace which can generate display texts.

Update 07 Sept 2010: A prototype has been created for this module, based on the specification included in the slides above. 

Update 18 Nov 2010: Sample screen shots will be added to this page to demonstrate how the prototype works.

Examples:

Here are a few examples of the prototype. Note that dates are not checked for correctness against a calandar, although boundaries for day and month are checked.

1. Date: Entering a year and segment.

2. Date : If day or month are entered, then 'Segment' is unselectable.

3. Period

4. Before (or After) : There's a default value for calculating 'Earliest Date' but it can be overridden.

5. Century

6. Century by year (like Century, but a different display format)

2. In the current system date display text is sometimes more detailed than the date ranges.

Typically this seems to be because there was confusion over how to enter a month/year in the current system.

Example : SMKDate id 484685. "From" and "To" dates identify a whole year, but the text identifies a single month. Text is "August 1961". "Date from" is Sunday, 1 January 1961 (22282) ,"Date to" is Sunday, 31 December 1961 (22646).

Action: Try to provide a means for users to enter month (and seasons) in a way which the current system does not.

3. Representation of dates in the current system.

Dates are stored in a table represented by the following columns:

• id (integer : unique identifier)
• gbdatedisplay (String: English display text translation)
• datetype (Controlled list : Date, Before, After, Circa, Period, Century, Decade, Millenium, CenturyByFirstYear)
• dateto (integer: Latest date)
• datefrom (integer: Earliest date)
• dateextent (Controlled list : 1st half, 2nd half, 1st quarter, 2nd quarter, 3rd quarter, 4th quarter, beginning of, end of, middle of)
• datedisplay (String: Danish display text )

Date timestamps (dateto and datefrom) stored in the current system are represented as integers, in such a way that 0 = 30.12.1899, 1 = 31.12.1899 etc. Recent dates have been staightforward to convert, but ancient dates have been more problematic. So far, the most successful method for converting these has been the Java Jodatime library (using its default ISO chronology). The JDT Calendar library resulted in errors (by insisting upon a Gregorian/Julian chronology which couldn't be properly reconfigured and didn't match the representation of our data). However, with dates pre 100AD we still have conversion problems and are awaiting input from the implementers of our current system.

4. Mapping to CollectionSpace date format.

The current (frequently changing) plan is to map all current fields into Collectionspace. The datetype and dateextent fields (see above) from the current system describe two sets of strings which are used to help the user generate a display text. By mapping these to the 'certainty' and 'qualifier' fields we can present the user with the expected user interface when editing data. It remains to be seen if this constitutes misuse of the CS schema.

Below are some examples. Note: This mapping is probably based on a misunderstanding of the CS schema especially the earliest/latest dates, which here a interpreted as 'eariest/latest possible' dates.