Closed BenjaminMoe closed 5 months ago
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.
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.
Action item: Update top level credentials to use DateTime where relevant. Do not update individual credential subjects
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
@rhofvendahl Please review the agriculture credentials for any date issues. @mkhraisha please review the OG credentials for any date issues
@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)
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:
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.
PR #942 tackled this issue good to close
https://github.com/w3c-ccg/traceability-vocab/blob/main/docs/openapi/components/schemas/common/CTPAT.yml#L58
Value is a Datetime, should use Datetime for JSOn Schema
"dateOfLastValidation": "2022-01-06T11:50:00Z",