DDMS 4.1: Updated date handling

Description

(Imported from Google Code)
All DDMS elements that employ CombinedDateType can now support a new date format. The pattern for this format is:

YYYY-MM-DDThh:mmTZ
[0-9]{4}[0-9]{2}[0-9]{2}T[0-9]{2}:[0-9]{2}(Z|[-+][0-9]{2}:[0-9]{2})?

Affected dates:
ddms:dates/ddms:acquiredOn
ddms:dates/ddms:acquiredOn/ddms:searchableDate/@ddms:start
ddms:dates/ddms:acquiredOn/ddms:searchableDate/@ddms:end
ddms:dates/@ddms:approvedOn
ddms:dates/@ddms:created
ddms:dates/@ddms:infoCutOff
ddms:dates/@ddmsosted
ddms:dates/@ddms:receivedOn
ddms:dates/@ddms:validTil
ddmsrocessingInfo/@ddms:dateProcessed
ddms:temporalCoverage/ddms:approximableStart
ddms:temporalCoverage/ddms:approximableStart/ddms:searchableDate/@ddms:start
ddms:temporalCoverage/ddms:approximableStart/ddms:searchableDate/@ddms:end
ddms:temporalCoverage/ddms:approximableEnd/childText
ddms:temporalCoverage/ddms:approximableEnd/ddms:searchableDate/@ddms:start
ddms:temporalCoverage/ddms:approximableEnd/ddms:searchableDate/@ddms:end
ddms:temporalCoverage/ddms:start
ddms:temporalCoverage/ddms:end

Activity

Show:
Brian Uri
August 30, 2012, 9:50 AM

May be trickier than expected.

All dates are currently handled with the XMLGregorianCalendar class, which automatically handles the 4 XML Schema date types. The default implementation of this class does not trivially support the custom ddms date type.

Brian Uri
August 31, 2012, 12:57 AM

Brainstorms:
The date field accessors in DDMSence return an XMLGregorianCalendar, and this return type should not change (for backwards compatibility).

If the incoming date value is a ddmsateHourMinType date, it will fail to be loaded into the standard XMLGregorianCalendar implementation (com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl). I could create an extension that transforms the date by adding seconds (:00.0) to the lexicalRepresentation. This extension could be treated as an XMLGregorianCalendar, for the purposes of accessor return values, but would have some alterations:

  • the XML Schema DataType would be ddmsateHourMinType.

  • the XML Format of the return value would be the original XML value, without the added seconds.

Long-term, perhaps it makes sense to convert the return values of date accessors into XML Strings and then allow users to do what they will with the values. This remains the most true to the underlying data in the metacard at the expense of backwards compatibility.

Brian Uri
September 1, 2012, 6:14 AM

Rev 773 refactors the existing codebase in the following ways:

  • XML Date caching is no longer performed on any of the date fields that will support the new DDMS date type. (This does not impact XML date caching for ISM attributes, since they only use xsd:date).

  • Each field that was previously Gregorian-based now has a getXxxxString() field that returns the raw XML format of the date. It is now up to the user to format as desired.

  • XMLGregorianCalendar-based accessors are deprecated. They will still work for the original 4 XSD date types, but will return null whenever a DDMS custom type is encountered.

This revision lays the groundwork for the real development, which now just consists of updating the Util date validation method to support the new DDMS custom type.

Brian Uri
September 1, 2012, 6:40 AM

Complete in Rev 774.

Fixed

Assignee

Brian Uri

Reporter

Brian Uri

Labels

None

Fix versions

Priority

Medium