Date And Time Service Description and Assumptions

Description

A utility service that provides support for date and time operations.

These operations provide support for the temporal attributes of other entities, such as:

• Recording the dates and times of a wide range of meaningful system events.
• Specifying the duration of time-bound events, such as loans, exhibitions, and temporarily-granted access permissions.
• Facilitating searches and reporting based, in part, on date and time ranges (e.g. "collection objects accessioned within the last week" or "collection objects scheduled for conservation activity during March 1-20 of the current year").

Operations supported may include:

• Date and time addition and subtraction, in part in support of such concepts as "last week," "this month", and "90 days from now."
• Date and time ranges, in support of time-bounded entities, such as loans, exhibits, and temporary access permissions.
• Date and time format conversion, in support of customization (including Internationalization) and import.
• Time zone handling.
• Generating timestamps.

Assumptions

Scope

• This service will apply to system dates and times: the dates and times of meaningful collections management events modeled by the CollectionSpace system, such as the date and time that an object was accessioned, loaned, exhibited, moved, or covered by conservation activities; dates and times related to an insurance contract or shipping manifest; or a date and time range during which temporary access permissions might be granted to a Principal.

• This service will not attempt to represent dates and times, or named time periods, that might be encountered in the context of CollectionObject metadata or other forms of Annotations, such as "203 BC," "1962 CE," "European Renaissance," "Han Dynasty," or "Mesozoic Era."
  
  If there is a need to support other types of dates and times, or named time periods, this should be carried out by a separate service or code base. For one possible starting place, please see Petras, Larson and Buckland's 2006 paper, Time period directories: a metadata infrastructure for placing events in temporal and geographic context

Calendar Systems

• This service will default to using the Gregorian Calendar system.
  
  It may be possible, during implementation, to create an abstraction layer to more readily permit the use of other calendar systems (e.g. Islamic, Hebrew) for representing system dates and times, in the event that might be a future requirement for the CollectionSpace system.

Date and Time Formats

• This service will inherently accept any of several widely-used input formats for dates and times.

• This service will allow customization - based on regular expressions or similar patterns - that will permit the use of other custom date and time input formats.

• For input date and time formats where years are represented with fewer than four digits (required to unambiguously designate years in the Gregorian Calendar), default assumptions about assigning these dates to a century will be used and documented.

• The default output format for dates and times, unless otherwise customized for a locale or institution, will be one or more default profiles of ISO 8601, the International standard for date and time formatting. (A 1997 W3C Note, Date and Time Formats, provides some suggestions for selecting these profiles.) There are two excellent general introductions to the ISO 8601 standard:
  
  • Markus Kuhn, A summary of the international standard date and time notation
  • Jukka "Yucca" Korpela, Info on ISO 8601, the date and time representation standard

• This behavior generally confirms with Jon Postel's maxum, "Be liberal in what you accept, and conservative in what you send."

Time Zones

• Deployments of the CollectionSpace service may be hosted in a different time zone than users of the service.

• Users of a deployment may simultaneously be located in two or more time zones.

• The core date and time framework/library will require periodic updates to time zone data, as various world governments make changes to that data.

Key Concepts

• Especially things that become common sense, and so usually missed by new reviewers

Dependencies

• Services with potential dependencies on this service include:
  • Notification
  • Scheduler
  • IDs, but only to the extent that certain forms of IDs may incorporate timestamps.

• Any entity services whose data models include temporal attributes may potentially have some dependencies on this service.

Background Documentation

• If we have notes from community design meetings, link to them here.
• If we have relevant sections in Spectrum or another such document, link to them here (or cite section numbers, etc.)

Key Team Members

• (Name(s) of members) is/are the primary tech team member(s) for this service
• Need to identify the community members acting as Domain Experts.