Date string should be switched to Datetime

[BenjaminMoe]

https://github.com/w3c-ccg/traceability-vocab/blob/main/docs/openapi/components/schemas/common/CTPAT.yml#L58

  dateOfLastValidation:
    title: Date of Last Validation
    description: >-
      Date of last validation.
    type: string
    $linkedData:
      term: dateOfLastValidation
      '@id': https://schema.org/Date

Value is a Datetime, should use Datetime for JSOn Schema
"dateOfLastValidation": "2022-01-06T11:50:00Z",

[TallTed]

Please confirm whether this is really just a DATE (as the name suggests) or really a DATETIME (as the sample value suggests) when recorded on existing paper forms and/or electronic systems.

If the latter, and if possible, I would suggest changing the attribute from dateOfLastValidation to timeOfLastValidation or perhaps better datetimeOfLastValidation or timestampOfLastValidation. Even if dateOfLastValidation cannot be changed, if the value really is meant to be a datetime/timestamp, I would suggest changing the title, description, and any other human-focused info to reflect this -- i.e., --

title: Datetime of Last Validation
description: >-
   Datetime of last validation.

-- or --

title: Timestamp of Last Validation
description: >-
  Timestamp of last validation.

[brownoxford]

Discussed on call, confirm that field is datetime not just date. We would want to be more specific and define this as a datetime and not just a string. We also want to update the title to indicate that time is involved, not just date.

[mkhraisha]

Action item: Update top level credentials to use DateTime where relevant. Do not update individual credential subjects

[mgh128]

GS1 EPCIS 2.0 casts values of its eventTime and recordTime fields to an xsd:dateTimeStamp data type (see https://www.w3.org/TR/xmlschema11-2/#dateTimeStamp ), which requires an explicit time zone offset to be specified, to avoid ambiguity on a global basis about when an event occurred, especially if shipments might cross multiple time zones.

See for example inside https://ref.gs1.org/standards/epcis/epcis-context.jsonld

[mkhraisha]

@rhofvendahl Please review the agriculture credentials for any date issues.
@mkhraisha please review the OG credentials for any date issues

[rhofvendahl]

@mkhraisha did we resolve to default to date & only use datetime if time is needed? (meeting notes weren't uploaded for that one and my own notes are spotty)

[mgh128]

In the GS1 EPCIS open standard for sharing visibility event data (traceability data), multiple events might be recorded within the same day for a particular physical object or shipment, so to ensure that these can be sorted into chronological order, we have used xsd:dateTimeStamp for all typed values for all of the following properties/fields:

• epcis:eventTime - when an event actually occurred
• epcis:recordTime - when it was captured (stored) in an event repository
• epcis:time - the time when business relevant sensor data was measured
• epcis:startTime - the start of a time range when business relevant sensor data was measured
• epcis:endTime - the end of a time range when business relevant sensor data was measured
• epcis:declarationTime - the time when a declaration of error was made

xsd:dateTimeStamp has the advantage of requiring the timezone offset to be specified, whereas it's optional in xsd:dateTime. Further details at https://www.w3.org/TR/xmlschema11-2/#dateTimeStamp

For timestamps such as the date of issue of a certification, xsd:date might provide sufficient precision for many applications, but for event data, I'm sure that xsd:dateTimeStamp would be the most robust choice you can make.

EPCIS also includes a field epcis:eventTimeZoneOffset that explicitly indicates the time zone offset that was in effect at the time and place where the event occurred, so even if all eventTime values were to express their timestamps using UTC/GMT (:Z) rather than an explicit +hh:mm or -hh:mm for events captured across multiple time zones, epcis:eventTimeZoneOffset still makes it possible to determine what the corresponding local time would have been at that location when the event happened.

I hope this helps.

[mkhraisha]

PR #942 tackled this issue good to close