Een veelgemaakte fout is het incorrect toepassen van zomer- en wintertijd. In de zomermaanden levert dit een foutmelding op bij observaties die rond middernacht plaatsvinden. Een voorbeeld van zo’n foutmelding is:

Datumdeel van Tijdmeetwaardepaar.tijdstip meting (MeasurementTVP.time) = (2016-08-01T00:00:00+02:00, JJJJ-MM-DDTUU:MM:SS+UU:MM) is niet correct: moet gelijk zijn aan Observatieperiode.einddatum (ObservationPeriod.endDate) = (2016-07-31, JJJJ-MM-DD).

In dit voorbeeld is de aangeleverde waarde die de foutmelding veroorzaakt 2016-07-31T23:00:00+01:00. Op 31-07-2016 gold in Nederland de zomertijd en was de juiste tijdsaanduiding voor een lokale tijd van 11 uur 's avonds 2016-07-31T23:00:00+02:00. De BRO volgt de ISO8601 standaard en rekent de aangeleverde tijdsaanduiding 2016-07-31T23:00:00+01:00 om tot een waarde van 2016-07-31T23:00:00+02:00. Deze aangepaste tijdsaanduiding 2016-07-31T23:00:00+02:00 leidt tot een GMT/UTZ datum 2016-08-01. En daarvan is het datumdeel niet gelijk aan de Observatieperiode.einddatum. Bij het correct toepassen van de zomer- en wintertijd zal deze foutmelding niet meer optreden. Dit verklaart tevens waarom in de foutmelding een tijdsaanduiding genoemd wordt die niet exact overeenkomt met de tijdsaanduiding in de XML.

Een uitgebreidere toelichting vind je hieronder:

GLD is het eerste registratie object waarvoor het nauwkeurig aanleveren van tijdstippen relevant is. In computersystemen worden tijdstippen absoluut vast gelegd. Dit wordt gedaan door het aantal milliseconden (of nanoseconden) te tellen ten opzichte van 1970, de zogenaamde Unix Epoch. Dit is het aantal tikken (milliseconden, nanoseconden, etc.) sinds 1 januari 1970 ten opzichten van de Greenwich Meridiaan (0 meridiaan). Dit wordt ook wel aangegeven als UTC.

Gegevens in de BRO worden middels brondocumenten naar de BRO gebracht. Deze brondocumenten zijn opgesteld in XML. XML is een tekstformaat. Dit betekent dat het door mensen kan worden gelezen. Dit is de reden dat er niet een nummertje (de Unix Epoch) maar een leesbaar tijdstip wordt verstuurd. Alhoewel XML door zowel mensen als machines (computers) kan worden gelezen, is interpretatie door mensen soms lastig. Het overdragen van tijdstippen (in tekst formaat) is gestandaardiseerd in een internationale ISO standaard: ISO 8601. Het probleem hierbij is dat dit altijd ten opzichte van een lokale setting gebeurt. 8:45 (het huidige tijdstip terwijl deze tekst wordt getypt) is niet hetzelfde tijdstip in Nederland als in bijvoorbeeld Groot Brittannië. Tijdzone en lokale afspraken (zomer/wintertijd) bepalen hoe wij het tijdstip zoals wij dat van een klok lezen moeten vertalen naar een absoluut tijdstip (zoals de unix epoch) die geschikt zijn voor opslag. Er is dus meer context nodig om een tijdstip te interpreteren. Lokale informatie ten tijde van het tijdstip is relevant, zeker voor historische informatie. Zie het onderstaande lijstje bijvoorbeeld (bron wiki)

  • 1916-1939: voor de vaststelling van de duur van de zomertijd werden verschillende regels toegepast, zoals blijkt uit de jaarlijkse publicaties in het Staatsblad. De vroegste begindatum was 26 maart (in 1922), de laatste einddatum 8 oktober (in 1922, 1933 en 1939).
  • 1940-1942: ononderbroken zomertijd van 16 mei 1940 tot 2 november 1942. In 1940 werd ook omgeschakeld van Amsterdamse Tijd naar Midden-Europese Tijd, op last van de Duitse bezetter. In deze tijd werd het in de winter pas rond 9:30 uur licht. 's Avonds daarentegen bleef het dan tot 18:00 uur licht.
  • 1943: zomertijd van 29 maart tot 4 oktober
  • 1944: zomertijd van 3 april tot 2 oktober
  • 1945: zomertijd van 2 april tot 16 september
  • 1946-1976: geen zomertijd
  • 1977-1980: zomertijd loopt van de eerste zondag van april tot de laatste zondag vóór 2 oktober. De vroegste begindatum was 1 april (in 1979), de laatste einddatum 1 oktober (in 1978).
  • Sinds 1981 gelden de regels zoals vastgesteld in een richtlijn van de Europese Unie.

Om rare sprongen in tijdseries te voorkomen is het belangrijk om de ISO 8601 standaard correct toe te passen. De meeste computertalen doen dit automatisch goed. Ook de verouderde Java 'Date' bijvoorbeeld.

De landelijke voorziening zal (net zoals andere computer systemen) het ISO 8601 formaat terugrekenen naar een absolute tijd. Dit gebeurt ook voor het vergelijken van datum delen. Als per ongeluk de verkeerde tijdzones worden opgevoerd (bijvoorbeeld de wintertijd +01 op een tijdstip in de zomer in plaats van +02) dan wordt rond middernacht een validatie afgekeurd (hij valt tenslotte op een andere datum). Dit is, constateren we, een veel voorkomende fout.

Online zijn er een verschillende tools te vinden die tijdstippen vertalen. Bijvoorbeeld; https://dencode.com/en/date/iso8601of https://www.timestamp-converter.com/

Bijvoorbeeld de volgende tijdstippen in Nederland:

  • 2019-02-01T09:00:00+01:00 = Feb 1, 2019, 9:00:00 AM
  • 2019-03-31T00:00:00+01:00 = Mar 31, 2019, 12:00:00 AM
  • 2019-04-01T00:00:00+01:00 = Apr 1, 2019, 1:00:00 AM (let op: dit is wintertijd notatie in zomertijd)
  • 2019-04-01T00:00:00+02:00 = Apr 1, 2019, 12:00:00 AM (merk op: de +02:00)
  • 2019-05-01T00:00:00+02:00 = May 1, 2019, 12:00:00 AM

Het is dus belangrijk dat de juiste tijdzone wordt opgevoerd om tijdstippen correct leesbaar te houden. Voor de lezer is dit de lokale tijd. De tijdzone informatie bepaald de "offset" ten opzichte van UTC (of voor het gemak: GMT). De afwezigheid van een tijdzone leidt tot een afwijzing van het brondocument. Bijvoorbeeld: "Tijdmeetwaardepaar.tijdstip meting (MeasurementTVP.time) = 2019-01-01T00:26:00, (Tijdzone ontbreekt) waarde is niet correct."