The date/time field type specification should not contain the "or, if not, a format field must be provided." and should read as follows:
For more information, see the mailing list thread: Calendar fields (date/time)
@ldodds interested in your thoughts here - may connect with #96 which extends type field to allow xsd types (which include date stuff IIRC).
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.
@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.
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:
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.
[jts][m]: make date formats stricter for default ISO format - fixes #104
- and define value of fmt:PATTERN for dates - fixes #200.