Omgaan met tijdzones in datatype DateTime

[PB-GNM]

Recent is aan Geonovum gevraagd hoe om te gaan met tijdzones in OGC-API's in het datatype DateTime.
Daarvoor is onderzocht wat bestaande standaarden hierover schrijven.

Er zijn drie manieren om om te gaan met de betreffende tijdzone:

1. UTC (Z) (vb.: 2018-02-12T00:00:00Z)
2. Timeoffset t.o.v. UTC (vb.: 2018-02-12T00:00:00+02:00)
3. geen van beide (vb.: 2018-02-12T00:00:00)

Relevante standaarden schrijven het volgende:

• RFC 3339, 5.6: geeft timeoffset als optie via verwijzing naar ISO 8601
• ISO 8601: geeft timeoffset als optie
• OGC-API-Features: requirement 26-E verwijst naar RFC3339, 5.6
• OGC-API-Maps: gebruikt timeoffset in voorbeeld
• JSON-schema 2020-12: JSON-schema 2020-12 geeft timeoffset niet als optie
• UML2JSON best practice: UML2JSON best practice geeft timeoffset wel als optie
• JSON-FG: JSON-FG staat geen timeoffset toe
• Geopackage: Verwijst naar ISO 8601 maar is strikter: Alleen UTC middels Z is toegestaan

Voor zover ik heb kunnen vinden staat hierover niets in de ADR geschreven.
Met dit issue stellen we daarom voor de volgende regel op te nemen in de ADR:
Gebruik altijd een Z of een timeoffset, maar geen van beide gebruiken, is niet toegestaan. De Z moet zowel voor input als output van de API ondersteund worden. De timeoffset is optioneel voor zowel Input als output.

[TimvdLippe]

Hier is een issue voor de ADR al aangemaakt (Logius-standaarden/API-Design-Rules#195) en er staat een voorstel wijziging klaar (Logius-standaarden/API-Design-Rules#252) die bij het TO van volgende week wordt besproken (https://github.com/Logius-standaarden/Overleg/tree/main/API/2025-09-02). Preview van de regel: https://logius-standaarden.github.io/Publicatie-Preview/API-Design-Rules/date-time/#/core/date-time

[PB-GNM]

Hier is een issue voor de ADR al aangemaakt (Logius-standaarden/API-Design-Rules#195) en er staat een voorstel wijziging klaar (Logius-standaarden/API-Design-Rules#252) die bij het TO van volgende week wordt besproken (https://github.com/Logius-standaarden/Overleg/tree/main/API/2025-09-02). Preview van de regel: https://logius-standaarden.github.io/Publicatie-Preview/API-Design-Rules/date-time/#/core/date-time

Dank voor deze toevoeging. (Logius-standaarden/API-Design-Rules#195) is nog iets strenger, omdat daarin output altijd in UTC moet met een Z.
Daar zal goed over nagedacht zijn en vooralsnog is dat ook Oké en sluit ik dit issue.

[BvanRaaij]

RFC 3339 is recentelijk opgevolgd door IETF RFC 9557. Klein verschil rond interpretatie van Z:

This specification updates Section 4.3 of [RFC3339], aligning it with the actual practice of interpreting the offset Z to mean the same as -00:00: "the time in UTC is known, but the offset to local time is unknown".

Section 4.3 of [RFC3339] is revised to read as follows:

If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "Z". (The original version of this specification provided -00:00 for this purpose, which is not allowed by [ISO8601:2000] and therefore is less interoperable; Section 3.3 of [RFC5322] describes a related convention for email, which does not have this problem). This differs semantically from an offset of +00:00, which implies that UTC is the preferred reference point for the specified time.