The current version of the DDLm has two content type for specifying time: Date and DateTime. The Date type is intended to store an ISO date (YYYY-MM-DD) while DateTime allows to record either an RFC full-date (YYYY-MM-DD) or an RFC date-time (YYYY-MM-DDThh:mm:ss+timezone_offset). This works great in most cases, however, in our applications we keep running into situations where we need to record timestamps that are only reliably known up to the precision of minutes or hours (mostly when data is input by a human-operator). I understand that changing DateTime to allow such arbitrary precision maybe undesirable due to backward compatibility concerns, but maybe a new type (e.g. called PartialDateTime), intended to record human activity rather than machine activity, could be introduced?
Several possible approaches:
-
The new data type could be defined same DateTime, but with the additional option to specify a partial date (up to the precision of hour or minutes). This would probably be the least work, but would also make the DDLm specification slightly less precise as partial time is not formally defined as a construct anywhere in RFC 3339.
-
There is also the W3C Date and Time Format which while also not backed by a grammar, provides a good description and several nice examples.
-
Alternatively, the data type could be based on the iso-date-time construct as defined in RFC 3339. It is quite similar to the RFC date-time one that is currently used in the DDLm, however, it is much more flexible (in some cases even too much, I would say), e.g.:
-- It allows to specify a partial date (without a month or a day).
-- It allows to specify a partial time.
-- It allows omitting date and time separators (e.g. 20250401 is a valid date).
-- It allows to specify a partial timezone offset (without minutes) or to omit it altogether.
-
Another option would be to refer directly to ISO 8601, but it is a closed standard, generally behind a paywall.
Do any of these sound acceptable? We could prepare a PR based on your response.
This issue was raised in response to issue #1713 on the COD bugtracker.
I also at @sauliusg as he wanted to be included in the conversation.
The current version of the DDLm has two content type for specifying time:
DateandDateTime. TheDatetype is intended to store an ISO date (YYYY-MM-DD) whileDateTimeallows to record either an RFC full-date (YYYY-MM-DD) or an RFC date-time (YYYY-MM-DDThh:mm:ss+timezone_offset). This works great in most cases, however, in our applications we keep running into situations where we need to record timestamps that are only reliably known up to the precision of minutes or hours (mostly when data is input by a human-operator). I understand that changingDateTimeto allow such arbitrary precision maybe undesirable due to backward compatibility concerns, but maybe a new type (e.g. calledPartialDateTime), intended to record human activity rather than machine activity, could be introduced?Several possible approaches:
The new data type could be defined same
DateTime, but with the additional option to specify a partial date (up to the precision of hour or minutes). This would probably be the least work, but would also make the DDLm specification slightly less precise aspartial timeis not formally defined as a construct anywhere in RFC 3339.There is also the W3C Date and Time Format which while also not backed by a grammar, provides a good description and several nice examples.
Alternatively, the data type could be based on the
iso-date-timeconstruct as defined in RFC 3339. It is quite similar to the RFCdate-timeone that is currently used in the DDLm, however, it is much more flexible (in some cases even too much, I would say), e.g.:-- It allows to specify a partial date (without a month or a day).
-- It allows to specify a partial time.
-- It allows omitting date and time separators (e.g. 20250401 is a valid date).
-- It allows to specify a partial timezone offset (without minutes) or to omit it altogether.
Another option would be to refer directly to ISO 8601, but it is a closed standard, generally behind a paywall.
Do any of these sound acceptable? We could prepare a PR based on your response.
This issue was raised in response to issue #1713 on the COD bugtracker.
I also at @sauliusg as he wanted to be included in the conversation.