Date validation for 360Giving in CoVE

[caprenter]

I've got a feeling that there are few things to clarify around date validation for 360Giving data in CoVE.

I think all dates are supposed to be supplied as YYYY-MM-DD

We've established that we have to 'turn date checking on' in this issue: https://github.com/OpenDataServices/cove/issues/188

and I think we specify or create our own rules.

What do we need to be aware of?

[timgdavies]

There a couple of issues to unpack here:

(1) JSON Schema handling of date-time.

Re-reading through the docs, it seems JSON Schema only has a date-time validation keyword, not date only.

It validates against RFC 3339, section 5.6 which appears to suggest date-time is only valid with a full time included.

We currently use date-time in the 360Giving JSON Schema (e.g.), but we really only want to ask for a date.

We might want to therefore update the 360Giving Schema to remove the date-time validation, and instead think about how to validate YYYY-MM-DD dates differently.

(2) Flatten tool handling of spreadsheet dates

I'm not sure whether flatten-tool currently converts date cells into YYYY-MM-DD, or already requires they are formatted in YYYY-MM-DD

I would suggest we should be fairly permissive here in the spreadsheet conversion, allowing that someone might enter the date as DD/MM/YYYY, but that as long as the column is typed, flatten tool can extract the correct date.

Whatever we do, we check how it is documented.

(3) OCDS vs. 360

OCDS needs to be much more strict on having date-time, rather than date.

In the CoVE architecture we might want to consider how we choose strictness of validation in different contexts.

[caprenter]

Great - thanks - assigned to @kindly as I think this ties in with his investigations last week

[caprenter]

With 360Giving there is a dateModified field that could be a datetime field. Should that also be handled as YYYY-MM-DD?

Otherwise I can't see any other date fields that might want a time stamp as well (as Tim said above)

[timgdavies]

I think we should be forgiving of that being only date (but should accept date-time as well) - as I imagine some people will be maintaining that manually - and so would struggle with full date-time.

[kindly]

My conclution to this is that we should change the date-time validation to be essentially "date-time or date" validation. @timgdavies @caprenter what do you think? shall we also use this for ocds?

[timgdavies]

This sounds good for 360.

For OCDS we need to be stricter about date-time = date-time.