Datums en tijdzones: waarom een order op de verkeerde dag landt

Waarom een order op de verkeerde dag terechtkomt

Een tijdstip is een moment, een datum is een vak in de kalender. Welk vak bij een moment hoort, hangt af van de tijdzone. Order 10482 wordt geplaatst op 1 oktober 2026 om 00:30 Nederlandse tijd. Shopify geeft dat moment door als 2026-09-30T22:30:00Z: 22:30 in UTC, de wereldtijd zonder zomertijd.

In Business Central is de orderdatum (orderDate) een datum zonder tijd. De koppeling moet dus van het tijdstip een datum maken. Neemt hij de eerste tien tekens van de tekst, dan staat er 2026-09-30. Rekent hij eerst om naar Nederlandse tijd, dan staat er 2026-10-01. Het verschil is één dag, maar die dag valt in een andere maand, een ander kwartaal en een andere btw-periode.

Het venster waarin dit gebeurt is 2 uur per nacht in de zomer en 1 uur in de winter. Een webshop die na middernacht weinig verkoopt merkt het een tijd niet. Tot de maandafsluiting een paar orders van de eerste van de maand in de vorige maand laat zien, of de omzet per dag in het ERP niet overeenkomt met het overzicht van de webshop.

Wat systemen precies versturen

Elk systeem geeft tijden op zijn eigen manier door. Deze zijn op 3 oktober 2026 nagelezen in de documentatie van de leverancier.

De twee WooCommerce-velden laten het risico het best zien. Beide teksten zien eruit als een gewoon tijdstip, en geen van beide zegt in welke tijdzone het staat. Dat weet je alleen uit de documentatie van WooCommerce: het ene veld staat in de tijdzone die in WordPress is ingesteld, het andere in GMT. Staat de site op UTC in plaats van Amsterdam, dan zijn beide velden gelijk en klopt geen van beide met de Nederlandse kalender.

{
  "id": 10482,
  "date_created": "2026-10-01T00:30:00",
  "date_created_gmt": "2026-09-30T22:30:00",
  "date_paid_gmt": "2026-09-30T22:31:04"
}

Shopify legt de tijdzone van de winkel vast in het veld ianaTimezone van het object Shop, bijvoorbeeld Europe/Amsterdam. Business Central bewaart een datum met tijd altijd in UTC en toont hem in de tijdzone van de gebruiker, volgens de documentatie van Microsoft. Wat je in het scherm ziet is dus niet wat de API teruggeeft.

De regel die hieruit volgt: een tijdstip reist in UTC, met de tijdzone erbij. Pas op het moment dat er een datum van gemaakt wordt, rekent de koppeling om naar de tijdzone van de administratie. Dat gebeurt op één plek, zodat niet twee stappen elk een eigen omrekening doen.

Zomertijd: het uur dat niet bestaat en het uur dat twee keer komt

Alle EU-landen gaan op de laatste zondag van maart naar zomertijd en op de laatste zondag van oktober terug, zo staat in richtlijn 2000/84/EG (Europese Commissie). In Nederland gaat de klok in 2026 op 29 maart van 02:00 naar 03:00 en op 25 oktober van 03:00 terug naar 02:00.

Wat een planner doet met een run op 02:30 in de nacht van de wisseling, verschilt per planner: overslaan, direct uitvoeren of twee keer draaien. Een nachtelijke import die twee keer draait kan twee keer dezelfde boekingen maken als hij niet op dubbelingen controleert. Wie runs in UTC plant, heeft er geen last van.

De laatste twee regels van de tabel tonen de tweede fout: een vaste correctie. Een koppeling die bij elk UTC-tijdstip "plus één uur" optelt, zit het halve jaar een uur mis. De omrekening hoort te gaan via de naam van de tijdzone, Europe/Amsterdam, niet via een vast verschil.

Hetzelfde speelt bij het ophalen van wijzigingen. De WooCommerce REST API filtert met modified_after en leest dat tijdstip in de tijdzone van de site, tenzij dates_are_gmt=true wordt meegestuurd. Een koppeling die zijn laatste run in UTC onthoudt en het filter zonder die vlag verstuurt, vraagt in de zomer om alles van 2 uur na het echte moment. De wijzigingen uit die 2 uur komen nooit binnen.

03-04: één tekst, twee datums

In leveranciersbestanden staan datums als tekst, en de volgorde van dag en maand staat nergens bij. 03-04-2026 is in Nederland 3 april. Volgens de Amerikaanse volgorde is het 4 maart. Dat is 30 dagen verschil op een verwachte leverdatum.

Een dag boven de 12 verraadt de volgorde, maar een bestand waarin alle datums in de eerste 12 dagen van de maand vallen, zegt niets. Gokken op basis van de eerste regels werkt tot de dag dat het misgaat. De koppeling legt daarom per leverancier het formaat vast, bijvoorbeeld DD-MM-JJJJ, en stuurt elke waarde die daar niet in past naar de controlelijst. Een bestand dat iemand in Excel opent en opslaat, kan daarna ineens een ander datumformaat of serienummers bevatten. Meer daarover staat in CSV- en Excel-bestanden van leveranciers.

Weeknummers: ISO tegen Excel

Leveranciers en vervoerders noemen een leverweek vaak alleen als nummer. Er zijn twee manieren van tellen. ISO 8601 begint de week op maandag en week 1 is de week met de eerste donderdag van het jaar. De standaardinstelling van de functie WEEKNUM in Excel begint op zondag en week 1 is de week waarin 1 januari valt, zo staat in de uitleg van Microsoft bij die functie.

Rond de jaarwisseling van 2026 op 2027 lopen ze uiteen:

2026 heeft volgens ISO 53 weken, omdat 1 januari 2026 op een donderdag viel. Een leverancier die "levering week 1" schrijft, bedoelt volgens ISO de week van 4 januari 2027 en volgens Excel de dagen van 27 december tot en met 2 januari. Voor een webshop die "verwacht in week 1" toont, is dat een week verschil in wat de klant leest.

Levertijd als duur of als datum

Een levertijd van "5 werkdagen" is een duur. "Verwacht op 12 oktober" is een datum. De ene is naar de andere om te rekenen, maar alleen met een werkdagenkalender, een lijst feestdagen en het tijdstip waarop de dag sluit.

Een rekenvoorbeeld: een order op vrijdag 2 oktober 2026 om 15:00, voor een sluittijd van 16:00, telt vanaf vrijdag. 5 werkdagen later is vrijdag 9 oktober. Dezelfde order om 16:30 telt vanaf maandag 5 oktober, en 5 werkdagen later is maandag 12 oktober. Een half uur verschil bij het bestellen wordt drie kalenderdagen verschil in de leverdatum. Voor die sluittijd moet de koppeling ook weer weten in welke tijdzone 16:00 bedoeld is. De velden en de rekensom staan uitgewerkt in levertijd of leverdatum.

Wat betekent dit voor je koppeling?

Per datumveld leggen we vast in welke tijdzone het binnenkomt, in welk formaat en welke tijdzone de administratie gebruikt. Tijdstippen gaan in UTC door de koppeling en worden op één plek omgerekend naar Europe/Amsterdam als er een orderdatum of boekdatum van gemaakt wordt. Geplande runs staan in UTC. Een datum die niet in het vastgelegde formaat past, komt op de controlelijst en wordt niet geraden. In de dry run zie je vooraf welke orders van de eerste van de maand in welke periode landen.

Datums zijn een van de velden in de orderstroom, naast adressen, bedragen en statussen. Het overzicht staat op orders, klanten en verzending, met de bijbehorende rekensommen in bedragen en btw mappen en adresvelden mappen. Vertel welke systemen je gebruikt, dan hoor je welke datumvelden ze sturen en waar omgerekend moet worden.