Date/time datatypes MUST be in ISO format #104

Closed
Stiivi opened this Issue Feb 23, 2014 · 5 comments

Projects

None yet

4 participants

@Stiivi
Stiivi commented Feb 23, 2014

The date/time field type specification should not contain the "or, if not, a format field must be provided." and should read as follows:

  • date: a date. This MUST be in ISO6801 format YYYY-MM-DD
  • time: a time without a date
  • datetime: a date-time. This MUST be in ISO 8601 format of YYYY-MM-DDThh:mm:ssZ in UTC time

For more information, see the mailing list thread: Calendar fields (date/time)

@rufuspollock
Contributor

@ldodds interested in your thoughts here - may connect with #96 which extends type field to allow xsd types (which include date stuff IIRC).

@ldodds
Contributor
ldodds commented Mar 3, 2014

See latest comment in #95 for date format specification. By default dates should conform to one of the XML Schema date types which covers, dates, date-time, time, etc. These have well-defined standard syntax.

But while publishers should be encouraged to use these formats for new datasets, I don't think it should be required: it ought to be possible to write a schema for existing data to help support re-use of data that is already being published. This lets us improve tooling whilst separately encouraging data publishers to adopt standard formats.

@Stiivi
Stiivi commented Mar 3, 2014

@ldodds Problem is not the format in this case. Problem is the incomplete date specification, in which case incomplete date != date. Therefore the fields should NOT be marked as date/time fields if they do not contain full date/time.

@ldodds
Contributor
ldodds commented Mar 3, 2014

I agree with you that fields should be defined to use the correct date type. There's also agreement in #95 that we should use XML Schema date types.

What I'm disagreeing about is the MUST for the specific date format you're proposing. I'd phrase it as:

  • an xsd:dateTime value MUST include date and time components
  • if not specified then the format of the value must match that defined in XML Schema, which includes time zone information. Data publishers SHOULD used the standard XSD date formats
  • if a date doesn't conform to a standard pattern, then the schema MUST include a datePattern which provides the necessary format string required to parse the date and time components from the field value
@Stiivi
Stiivi commented Mar 3, 2014

The actual format does not matter, I was just "fixing" the current specification. It only MUST include all the date/time components.

"if a date doesn't conform to a standard pattern" – am I as a tool writer REQUIRED to use this field or can I just refuse to process the dataset when the datePattern is filled? What if I just convert the field to string? The later might block further processing if that field is used as a date, or the processing might work, if the field is just passed around together with metadata.

EDIT: added clarification.

@rufuspollock rufuspollock added a commit that closed this issue May 26, 2015
@rufuspollock rufuspollock [jts][m]: make date formats stricter for default ISO format - fixes #104
 - and define value of fmt:PATTERN for dates - fixes #200.
854ed1e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment