Zum adressieren eines Tages ohne konkrete Uhrzeit muss der Datentyp "string" mit Format "date" gemäß OpenAPI Spec verwendet werden.
Codeblock title Date "SomeObject": { "properties": { "myDate": { "type": "string", "format": "date" } } } }Info title Bemerkung Im aktuellen Stand des API-Design, sind noch keine konkrete Fälle für dein Einsatz des Datenformat "date"identifiziert worden. Es werden entweder die Datenformate "date-time" oder "timeperiod" eingesetzt
Zum adressieren eines Tages mit konkreter Uhrzeit muss der Datentyp "string" mit Format "date-time" gemäß OpenAPI Spec verwendet werden. Bei der Angabe von Date-Time Werten muss zwingend die Zeitzone mit angegeben werden
Codeblock title DateTime "SomeObject": { "properties": { "myDateTime": { "type": "string", "format": "date-time" } } } }Zum adressieren einer Zeitspanne muss der Datentyp "TimePeriod" (s. TMF646 AppointmentManagementAPI) verwendet werden:
TimePeriod ist als common schema in TMF definiert:
...
| Codeblock |
|---|
...
| title | TimePeriod |
|---|
...
{ "$schema": "http://json-schema.org/draft-07/schema#", "$id": "TimePeriod.schema.json", "title": "TimePeriod", "definitions": { "TimePeriod": { "$id": "#TimePeriod", "description": "A period of time, either as a deadline (endDateTime only) a startDateTime only, or both", "type": "object", "properties": { " |
...
startDateTime": { " |
...
description": |
...
"Start of the time period, using IETC-RFC-3339 format", "type": " |
...
string", |
...
|
...
|
...
|
...
"format": " |
...
date-time", " |
...
examples": [ |
...
"1985-04-12T23:20:50.52Z", "2018-09-21T09:13:16-07:00" ] }, " |
...
endDateTime": { " |
...
description": |
...
"End of the time period, using IETC-RFC-3339 format", "type": "string", |
...
"format": "date-time", "examples": |
...
[ " |
...
1985-04-12T23:20:50.52Z", |
...
|
...
|
...
"2018-09-21T09:13:16-07:00" ] } } } } } |
| Info | ||
|---|---|---|
| ||
Für einige Anwendungsfälle wäre es sinnvoll "startDateTime" und/oder "endDateTime" als Pflicht zu definieren. Um den Datentyp TimePeriod aber in allen Anwendungsfällen anwenden zu können wurde im generischen Datentype TimePeriod darauf verzichtet → Kontextbezogene Definition von "startDateTime" und/oder "endDateTime" als Pflicht, mussen also als Regeln hinterlegt werden. |