Keep date precision in Date Maker and Date elements

[diplomatica]

need to allow for yyyy, mm-yyyy or yyyy-yyyy functionality in date field for metadata.

[gregjan]

Existing conversion strategy encodes the entirety of a java date/time to iso8601. This results in a false precision for date values like "2006".
A better way to handle such cases is to decorate the Date given to the conversion strategy with a precision wrapper that includes a precision field. The conversion strategy for the mapped element can use this to encode only to the available precision.

[gregjan]

The yyyy-yyyy pattern seems to be a date range. There are at least two ways of encoding a date range in mods, see date attributes on this page:

http://www.loc.gov/standards/mods/v3/mods-userguide-generalapp.html#list

1. We need to decide whether to use the / character in a single date element, for unparsed date ranges or the more specific form where two elements are combined using point='start' point='end' attributes.

2. The input of a range may come from two columns or a single column with a separator character, as is the case with the example "2005-2006". The crosswalk should allow one to map either situation while maintaining the precision of the original date. A field splitter widget could be used to split on the separator character, producing multiple outputs or this could be left to a google refine function. In either case the logic of mapping a date with original precision is the same, after the split. If we are to use separate elements for start and end (1), then the rest of the date range implementation is actually just two regular date elements within the same originInfo element. (I think the start/end pattern for encoding date ranges in MODS is more useful and simpler to parse.)

[gregjan]

Okay, ignoring the encoding question for date range, we have a feature for imprecise dates now. The Date Maker now takes an ordered list of date format strings. The first one to match is used. The most granular placeholder within the format string that matches determines the precision of the date.

So a pattern of yyyy/M would match 2001/05 and would have a precision of only "Month". When that date is recorded in ISO 8601 it is only recorded with month precision. So that date is output as 2001-05.

Since you can have multiple format strings in a list, you can now parse non-uniform date fields. So if some dates are written as 2001/05 and others as 05-2001, you can match both. If some dates only have a year, then you would add a yyyy pattern and it would be output as just "2001" in ISO 8601.

The date formats in use are now shown in the label for the Date Maker, making it easier to see all the formats at a glance.