New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Date/time datatypes MUST be in ISO format #104

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

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

This comment has been minimized.

Contributor

rufuspollock commented Feb 25, 2014

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

@ldodds

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment