Vandaag kreeg ik bij de bijeenkomst van de BGT een vraag over het stuurgegeven tijdstipBericht.
De stuurgegevens zijn geen onderdeel van een informatiemodel zoals RSGB, RGBZ of IMGeo en daarom wordt alleen het gebruik van het stuurgegeven tijdstipBericht beschreven, zie bijvoorbeeld paragraaf 4.3.2 op pagina 46 van de StUF 0301 standaard.
Als ik de vraag goed begrepen heb wordt in de Geo wereld gewerkt met tijdzones en wordt bij het verwerken het verschil tussen zomertijd en wintertijd meegenomen. Dit staat echter nergens vast en ook in het StUF0301.xsd schema staat tijdstipBericht gedefinieerd als een simpleType van het type String met een pattern [0-9]{8,17}.
Aangezien StUF berichten zelfbeschrijvend zijn, hoe kan een eventuele tijdzone en een indicatie of het winter- of zomertijd betreft meegegeven worden aan een tijdstipBericht?
Ik vermoed dat het nu niet mogelijk is om de tijdzone en een indicatie zomertijd/wintertijd in de stuurgegevens mee te geven.
Je zou zeggen dat je dus een extraElement zou moeten introduceren maar dat lijkt mij niet de bedoeling.
Een extraElement heeft immers betrekking op een entiteit en niet op een bericht.
Verder kan ik me voorstellen dat men in de verleiding komt om het melding element hiervoor te gebruiken maar ook dat lijkt me niet de bedoeling. Dat element heeft nl. in diverse berichten de functie om een code mee door te sturen.
In StUF 3.01 is het inderdaad niet mogelijk om tijdzones te specificeren in tijdstippen. Er wordt van uitgegaan dat alle tijdstippen in StUF betrekking hebben op de lokale tijdzone (inclusief zomertijd/wintertijd ) van Nederland. Indien tijdstippen in de BGT-berichten ook betrekking hebben op tijdzones van andere gebieden (Nederlandse Antillen, ...), dan zou je een vertaling kunnen definiëren tussen BGT- en StUF-berichten. De vraag is of dit in de praktijk voorkomt en nodig is. Zo ja, dan kun je hopelijk op basis van het stuurgegeven <zender> achterhalen uit welke land/regio het bericht komt en aan de hand daarvan een bepaalde tijdseenheid optellen of aftrekken van alle tijdstippen in het bericht om de tijd te corrigeren.
In StUF 3.02 gaan we de datum-tijd definitie van het GAB gebruiken en daarmee kunnen wel tijdzones (inclusief zomertijd/wintertijd) gespecificeerd worden.
Bedankt voor de reacties! Kunt u aangeven waar dit is vastgelegd zodat daar naar gerefereerd kan worden?
In de IMGeo standaard wordt de Nederlandse wintertijd ofwel CET (UTC+1) aangehouden voor alle datum en datumtijd velden. Echter valt het tijdstipbericht veld niet binnen die definitie.
Ik zou het echter bijzonder vreemd vinden als een tijdstipveld, waarin geen tijdzone meegegeven kan worden, twee verschillende tijdzones kan bevatten wintertijd (UTC+1) en zomer tijd (UTC+2). Dit betekend dat er bij de overgang van tijdszone er overlap is in tijd. Voor automatische systemen waarbij de volgorde van berichten gegarandeerd wordt door dit tijdstipbericht zou dit voor problemen zorgen. Daarnaast is het berekenen van de periode tussen twee berichten een stuk complexer of, tijdens overgang van tijdzone, niet mogelijk. Nagenoeg alle systemen (incl Oracle) die met tijden omgaan zullen intern UTC gebruiken of op z'n minst een vaste tijdzone. Voor een veld dat van datumtijd afhankelijk is zou altijd gerekend moeten worden afhankelijk van de gegeven tijd om te bepalen welke tijd er bedoeld wordt. Bij een vast tijdzone is dat simpelweg -1 of -2 uur.
U zult inmiddels begrijpen dat het mij nogal zou verbazen als deze fout in StUF zou zitten. Daarom zou ik graag zien waar dit vermeld staat. (Mijn originele vraag was eigenlijk wordt er UTC of UTC+1 gebruikt in StUF:)
Alvast bedankt!
Sjors, je hebt gelijk dat er in theorie in StUF 3.01 problemen kunnen ontstaan bij berichtverzendingen die plaatsvinden rondom de overgang tussen wintertijd en zomertijd en vice versa. Jij bent naar mijn weten de eerste die dit fenomeen gemeld heeft. In de praktijk heeft dit probleem zich blijkbaar tot nu toe niet (vaak) voorgedaan. De work-around is eenvoudig: verstuur geen bulkverzendingen rondom de overschakeling wintertijd/zomertijd ;-)
In StUF 3.02 is het probleem opgelost.
Bij de LV-WOZ (Kadaster) hebben we in het koppelvlak StUF-WOZ ook last van dit probleem. Naast tijdstipBericht en tijdstipRegistratie ook in tijdvakGeldigheid en tijdvakRelatie. Dat betekent dat ook in de materiële historie tijdstippen in de overgang tussen zomertijd en wintertijd niet eenduidig zijn. De genoemde work-around is dus niet afdoende.
Bij het Geo-BAG koppelvlak hebben wij ook te maken met tijdvakGeldigheid.
In StUF 3.02 (niet 3.01) staat het volgende:
“Als de tijdzone ontbreekt, dan wordt uitgegaan van de tijdzone voor Nederland.”
Welk van de twee Nederlandse tijdzones met “de tijdzone voor Nederland” bedoeld wordt is dan nog niet duidelijk.
Aangezien er voor StUF 3.01 geen documentatie lijkt te zijn gaan wij er vooralsnog vanuit dat, bij datum of datumtijd velden zonder tijdzone, altijd de Nederlandse winter tijd (UTC+1) gebruikt wordt. Tot nu toe zien wij dat de meeste andere partijen waarmee wij koppelen (Geo-BOR) dit ook hanteren.
Het lijkt me goed om dit nog te verduidelijken in StUF 03.02. Mijn voorstel zou dan zijn om de Nederlandse tijdzone nader te definiëren als de voor dat tijdstip geldende tijdzone in Nederland. Dit is voor alle tijdstippen met uitzondering van het uur 02:00 - 03:00 UTC+2 dat de tijdstippen overlappen door het terugzetten van de klok een eenduidige definitie die aansluit bij hoe er in de praktijk wordt gewerkt.
Voor dat uur met overlap is de tijdzone UTC+2. Het uur 03:00 - 04:00 UTC+2 kan alleen gespecificeerd worden door het expliciet opnemen van een tijdzone.
Als ik de laatste twee posts lees wordt over twee verschillende defaults voor tijdzones geschreven.
Sjors geeft aan dat bij een datum of datumtijd zonder tijdzone altijd de Nederlandse winter tijd (UTC+1) gehanteerd wordt, Maarten spreekt over de voor dat tijdstip geldende tijdzone in Nederland als hoe in de praktijk wordt gewerkt.
Dit laatste zou dan ook de Nederlandse zomer tijd kunnen zijn? Zoals ik het begrepen heb geeft die onduidelijkheid (want niet aangegeven) nu juist verwarring.
Aangezien Maarten voorstelt om in StUF 3.02 e.e.a. te verduidelijken heb ik een RFC opgevoerd in de onderhoudsverzoeken, te weten ONV0478.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Ik heb inderdaad een andere keuze gemaakt dan Sjors, omdat ik verwacht dat de huidige implementaties als tijdstip gebruiken het tijdstip zoals aangeleverd door hun eigen systeem. Voordat dit tijdstip in de huidige systemen wordt gebruikt wordt hier een eventuele tijdzone geëlimineerd en houd je afhankelijk van het tijdstip de Nederlandse zomertijd of wintertijd over. Om te voorkomen dat alle bestaande implementaties aangepast moeten worden kom ik tot de keuze om afhankelijk voor het tijdstip als default te kiezen voor de Nederlandse zomer- of wintertijd.
Door een en ander expliciet in de StUF-standaard op te nemen wordt de onduidelijkheid weggenomen.
In bijvoorbeeld augustus zijn alle tijden per definitie zomertijd, dus ik kan me goed vinden in de keuze van Maarten.
Om correct berekeningen en vergelijkingen te kunnen doen is vaak wel conversie naar 1 tijdzone (bijv. Nederlandse standaardtijd, d.w.z. wintertijd of UTC) nodig, terwijl bij de werkwijze die Sjors noemt geen conversie nodig is. Om die reden houd ik er wel rekening mee dat er toch software-aanpassingen nodig zullen zijn.
Aangezien wintertijd de standaardtijd is en zomertijd als uitzondering geldt lijkt het me logischer voor het uur met overlap de tijdzone UTC+1 (d.w.z. standaardtijd) te kiezen. Wat is de motivatie van de keuze voor UTC+2 tijdens het uur overlap?
Het voordeel van de gemaakte keuze is dat de volgordelijkheid van de berichten zonder tijdzone altijd correct is zonder dat je hoeft om te rekenen. De prijs die je betaalt, is dat je zonder een tijdzone te expliciteren één uur per jaar niet kunt aanduiden.
Ik kan me prima vinden in de suggestie van Rijk van Haaften om tijdens het uur overlap uit te gaan van UTC+1. in dat geval kunnen de tijdstippen tussen 02:00 - 03:00 UTC+2 alleen gespecificeerd worden door het expliciet opnemen van een tijdzone.
"de volgordelijkheid van de berichten zonder tijdzone altijd correct is zonder dat je hoeft om te rekenen"
Sorry, maar dit slaat nergens op. Als de tijd altijd in UTC+1 is dan is de volgordelijkheid juist makkelijker te bepalen/duidelijker.
Met de voorgestelde hack zal er juist altijd gerekend moeten worden terwijl dat bij alleen UTC+1 niet hoeft.
Ook is tijdstipBericht niet het enige attribuut waar dit op van toepassing is, zoals al eerder aangehaald is.
Bij de voorgestelde hack moet:
- Altijd gecontroleerd worden bij het invullen van het elk tijdstip (niet alleen tijdstipbericht) of het niet toevallig een overgangsuur is (bij lezen en schrijven) (een stuk lastiger dan UTC + 1)
Tevens als we 2 tijdzones hanteren moet:
- Bij elke datum(tijd) van bijvoorbeeld een geboortedatumtijd(beginGeldigheid) dat in een bericht staat worden bepaald wat toen de tijdzone was. Daarna pas dan kan de datumtijd met tijdzone opgeslagen worden. Als je namelijk de datumtijd zonder tijdzone opslaat dan wordt namelijk de huidige tijdzone gebruikt (of je moet rekenen bij het lezen van de datum). En die tijdzone is in de winter anders dan in de zomer en ook anders op Curaçao.
Bij het opnemen van een datum in een systeem heb je dus altijd een tijdzone nodig.
We kunnen er voor kiezen om:
- Voor elke tijd die binnenkomt en verstuurt wordt (ook tijden in het verleden) te gaan rekenen wat toen de tijdzone was.
+ nog een keer gaan rekenen of het niet toevallig dat overgangsuur was.
of
- Het is altijd UTC+1
Ook werd het argument gemaakt dat bestaande systemen hier goed mee om zouden gaan.
- Dat is geen argument om een bug in een nieuwe versie van de standaard te laten bestaan
- Ik verwacht dat dit gewoon fout gaat bij wintertijden die in de zomer gelezen worden. Het is alleen nog niemand opgevallen. Natuurlijk zal dit voor tijdstipbericht altijd goed gaan, maar niet voor tijden die in het verleden kunnen liggen.
Daarnaast vind ik dat je van een standaard mag verwachtten dat deze goed in elkaar zit. Een hack zoals hier wordt voorgesteld past daar absoluut niet in en het zelfde geldt overigens voor een datumtijd veld zonder tijdzone waarin twee verschillende tijdzones kunnen voorkomen.
Laat hier alstublieft door een (objectief) technisch persoon de juiste beslissing over maken.
P.s. De keuze van Maarten bij de hack voor UTC+2 is omdat je anders (met UTC+1) het probleem alleen maar erger maakt...
Waarom wordt er voor datum/tijd geen gebruik gemaakt van ISO standaard 8601 (W3 XMLSchema datetime)?
Zoals ik begrijp zullen nieuwe attributen ook zoveel mogelijk ISO met tijdzone indicatie zijn.
Een van de doelen van StUF is het hergebruik van software. Ik vermoed dat daarom niet alle attributen worden geüpdate naar een nieuwe formaat (misschien is dit ook wel gebeurt in de nieuwe versie, wij moeten echter werken met 3.01).
Het probleem hier is dat er nu eenmaal al tijdattributen zonder tijdzone indicatie bestaan. Zowel de 3.01 als de 3.02 documentatie van StUF geeft hier niet duidelijk aan welke tijdzone nou precies gebruikt moet worden in deze gevallen. Nu is dat dus implementatie afhankelijk en kan anders zijn bij verschillende standaarden.
Binnen StUF-Geo IMGeo wordt zowel ISO gebruikt voor datums en StUF tijdstippen gebruikt beide zonder tijdzone indicatie.
Dat hier geen tijdzone indicatie is toegevoegd is geen probleem aangezien in de IMGeo standaard is gedefinieerd dat alles in UTC+1 is. Het tijdstipbericht valt echter buiten die standaard en valt alleen binnen StUF.
Overigens als vast gelegd wordt dat tijd velden zonder tijdzone zowel UTC+1 als UTC+2 zijn dat spreken de StUF en IMGeo standaarden elkaar dus tegen.
Daarnaast heb ik deze week van het Geonovum vernomen dat ook voor het StUF Geo-BAG berichtenverkeer alle tijden in CET / UTC+1 zijn.
Tijdens de StUF Expertgroep van 15 maart 2017 wordt de uitwerking van Maarten goedgekeurd. Het voorstel van Sjors Donkers wordt wel als een goede oplossing gezien maar de consequenties zijn dermate groot dat de StUF Expertgroep daar niet voor kiest.
In maart dit jaar was ik er niet van op de hoogte dat er wettelijke regels bestaan voor dit probleem. Zie http://wetten.overheid.nl/BWBR0002288/1977-03-24
Als een tijdzone expliciet is vermeld is ondubbelzinnig (d.w.z. in termen van UTC) welk tijdstip wordt bedoeld. Is er geen tijdzone opgegeven, dan geldt voor het uur overlap "dat deze Midden-Europese Zomertijd betreft" (Artikel 2). Ik heb een kleine controle gedaan en standaarden (bijv. IANA) en software (bijv. Java) volgen inderdaad deze regelgeving.
Dit is exact het voorstel van Maarten op za, 18-02-2017 - 12.04u: "Voor dat uur met overlap is de tijdzone UTC+2". Mijn suggestie (en Maartens reactie daarop) van 20 februari is dus onjuist. Het lijkt me vanzelfsprekend dat we de Nederlandse wet en dus Maartens voorstel van 18 februari volgen.
Helaas kregen wij in maart berichten met daarin tijdstippen tussen 2:00 AM en 3:00 AM, met diverse problemen als gevolg. De wet zegt niets over dat uur bij overgang van wintertijd naar zomertijd. Er is wel een internationale richtlijn die daar het volgende over zegt:
Alle standaarden en software die ik heb gecontroleerd blijken inderdaad deze richtlijn te volgen. Dan moeten we dus voor 26 maart 2017 (idem voor 25-03-2018 et cetera) de tijden 2:00:00 AM t/m 2:59:59 lezen als identiek aan respectievelijk 3:00:00 AM t/m 3:59:59 AM. Dat komt erop neer dat we zulke tijden interpreteren alsof de zender is vergeten de klok vooruit te zetten en we dat als ontvanger alsnog voor de zender doen.
In de StUF-standaard is inmiddels het volgende opgenomen. Ik hoor graag van je of dit nu correct is.
"Datum en tijd worden in StUF0302 opgenomen zoals voorgeschreven vanuit de Gemeenschappelijk Afspraken Basisregistraties (GAB). Voor een datum/tijd definieert de StUF-standaard een restriction op xs:dateTime die het tijdstip 24:00:00 verbiedt en die de nauwkeurigheid van een tijdstip beperkt tot één milliseconde, doordat een tijdstip maar drie cijfers na de decimale punt mag bevatten. Het gebruik van de tijdzone is optioneel. Als de tijdzone ontbreekt, dan is de tijdzone de tijdzone voor Nederland, zoals die op dat tijdstip gold (als de zomertijd geldt dus UTC+2 en als de wintertijd geldt dus UTC+1). Voor het uur overlap bij het terugzetten van de klok van zomertijd naar wintertijd is de tijd UTC+2. Het tijdvak 03:00 - 04:00 UTC+2 kan hierdoor alleen gespecificeerd worden door het expliciet opnemen van een tijdzone. Deze keuze is gemaakt, omdat veel systemen die StUF gebruiken nooit een tijdzone hebben geregistreerd. Deze keuze waarborgt daarnaast de volgordelijkheid van de berichten."
Artikel 2 van http://wetten.overheid.nl/BWBR0002288/1977-03-24 geeft aan dat de tijd tijdens de overgang van de tijdzones als de Midden-Europese Zomertijd geïnterpreteerd dient te worden. Artikel 2 betekend M.I. echter niet dat de tijdzone waarin de tijd is opgeslagen MEZT moet zijn. De tijd kan opgeslagen zijn in UTC (als dat is afgesproken), maar dient aan de afnemer/gebruiker te worden getoond in de tijdzonde bepaald door de dan geldende wetgeving (deze omrekening is een standaard proces in software).
Om met datumtijden te kunnen rekenen is het noodzakelijk om te weten welke tijdzone erbij hoort. Anders is het niet mogelijk om de tijd tussen deze tijdstippen te bepalen.
- Door de datums in een variabele tijdzone op te slaan dient eerst de dan geldende wetgeving bepaald te worden en vervolgens bepaald te worden welke tijdzone toen van toepassing was. Hoe moeten we omgaan met tijdstippen voor 1977?
- Door een vaste tijdzone te gebruiken of een tijdzone mee te sturen is de tijdzone altijd ondubbelzinnig vast te stellen en zijn er ook geen problemen in de overlap van tijdzones.
Het gaat hier om communicatie in de berichten. Wij slaan inderdaad datums en tijden altijd op als UTC. We gebruiken daarvoor de ISO 8601 standaard in de opslag. Op basis van versie 2004, sectie 4.2.2.3 (reduced accuracy) van de standaard ondersteunen we ook onvolledige tijden.
De UTC tijdzone slaan we op met de uren afwijking van UTC ("+00"). De Z-notatie gebruiken we niet, wat helpt om lexicografisch sorteren in combinatie met onvolledige datums en/of tijden mogelijk te maken. Een onvolledig tijdstip beschouwen we als een tijdvak waarvan we het begin-tijdstip als bepalend beschouwen.
Bijvoorbeeld: "2017-03-26T06+00" = ["2017-03-26T06:00:00.000+00" ,"2017-03-26T06:59:59.999+00"]
We sorteren lexicografisch: "2017-03-25T23:59:59.999" < "2017-03-26T00+00" < "2017-03-26T00:00+00"
Daarmee kunnen we alle vereiste scenario's ondersteunen. De vragen (in elk geval van mijn kant) gaan nu vooral over hoe we berichten van bronhouders moeten interpreteren (in termen van UTC) en over hoe we de opgeslagen UTC-tijden correct communiceren naar afnemers.
Bij overgang van CEST naar CET in oktober is er een uur (direct nadat de klok een uur is teruggezet) dat in onze data in de database (UTC) wel voorkomt maar waarvoor in 3.01 geen formaat bestaat. We moeten daar nog een keuze in maken die we in dit forum nog niet hebben besproken. (De focus lag tot nu toe op het interpreteren van berichten van bronhouders.) Mijn voorstel is het eerstvolgende tijdstip te gebruiken dat wel te benoemen is.
In 3.02 is dit opgelost door het expliciet doorgeven van de bedoelde tijdzone mogelijk te maken. Het zal echter nog jaren duren voordat 3.02 volledig is doorgevoerd in de WOZ door alle bronhouders en alle afnemers.
Daarbij ga je ervan uit dat alle leveranciers zich netjes aan die te maken afspraak houden.
Nu wordt er bijvoorbeeld gesproken dat er geen tijdstippen uitgegeven mogen worden tijdens de overgang van tijdzone.
Uit ervaring blijkt dat niet iedereen alle regels implementeert wat er op neer komt dat wij alsnog deze tijdstippen moeten verwachten en moeten kunnen afhandelen. Een dergelijke afspraak heeft daarom w.m.b. geen toegevoegde waarde.
Voor 3.01 is het daarom mijn voorstel om tijdvelden in UTC te laten zijn. Zodat er nooit problemen zijn bij het overhalen van xml naar opslag en andersom van opslag naar xml.
Met mijn voorgaande bericht probeerde ik aan te geven dat dit ook binnen de wetgeving toegestaan is.