Description
Working through examples that are failing in the Travis continuous integration tests, it is clear that there are several properties that have an expected type of DateTime (eg. orderDate) have examples that do not have the full DateTime syntax (CCYY-MM-DDThh:mm:ss). In many use cases for these properties the time component is superfluous.
With definition of the term 'Date order was placed.', an expected Type of Date could probably be more appropriate. However there could be circumstances when the increased accuracy of DateTime would still be useful.
There are several examples of other properties (eg. startDate & endDate) where this circumstance is addressed by having both Date & DateTime included in the range.
Researching similar properties there are several that only have DateTime in their range that could benefit from having it extended to include Date, plus some that could similarly benefit by adding Time to their range.
I list these in the table below and recommend their ranges are expanded as such. This will provide a consistent approach to all such properties, and as a consequence also make several examples and code in the wild valid.
| Property | Current Expected Type | Proposed Additional Type |
|---|---|---|
| orderDate | DateTime | Date |
| validFrom | DateTime | Date |
| validThrough | DateTime | Date |
| paymentDueDate | DateTime | Date |
| expectedArrivalFrom | DateTime | Date |
| expectedArrivalUntil | DateTime | Date |
| dateRead | DateTime | Date |
| availabilityStarts | DateTime | Date |
| availabilityEnds | DateTime | Date |
| dateDeleted | DateTime | Date |
| dateIssued | DateTime | Date |
| checkoutTime | DateTime | Time |
| checkinTime | DateTime | Time |
| arrivalTime | DateTime | Time |
| departureTime | DateTime | Time |
| doorTime | DateTime | Time |
| endTime | DateTime | Time |
| startTime | DateTime | Time |