Tijdzones, UTC en Unix-timestamps begrijpen

Tijd lijkt eenvoudig totdat je probeert software te schrijven die het correct afhandelt. Een evenement gepland om "15:00" betekent verschillende dingen in Tokio, Londen en New York. Zomertijd verschuift klokken vooruit of achteruit — maar niet overal en niet op dezelfde data. Een timestamp die er correct uitziet in je lokale omgeving gaat kapot in productie omdat de server in een andere tijdzone staat.

Tijdzones zijn een van de meest betrouwbaar verwarrende onderwerpen in softwareontwikkeling. Dit artikel legt uit hoe ze werken, waar de complexiteit vandaan komt en hoe je de meest voorkomende fouten vermijdt.

Waarom tijdzones bestaan

De aarde draait 360 graden in 24 uur, wat betekent dat de zon op verschillende momenten op het hoogste punt staat afhankelijk van je lengtegraad. Vóór de 19e eeuw stelde elke stad zijn klokken in op de lokale zonnetijd — twaalf uur was wanneer de zon op het hoogste punt stond. Dit werkte prima totdat spoorwegen verre steden verbonden en een treinrooster één consistent tijdstip nodig had.

In 1884 kwamen afgevaardigden van 25 landen bijeen op de Internationale Meridiaanconferentie in Washington, D.C. en spraken af de wereld in 24 standaardtijdzones te verdelen, elk met een offset ten opzichte van de nulmeridiaan (0 graden lengtegraad) die door Greenwich, Engeland loopt.

In de praktijk volgen tijdzonegrenzen politieke grenzen, geen nette lengtegraadlijnen. China beslaat vijf geografische zones maar gebruikt één officiële tijd (UTC+8). India gebruikt UTC+5:30 — een halfuursoffset. Nepal gebruikt UTC+5:45. De werkelijke kaart van tijdzones is rommelig.

UTC vs. GMT

GMT (Greenwich Mean Time) is de gemiddelde zonnetijd bij het Royal Observatory in Greenwich. Het was meer dan een eeuw het tijdsreferentiepunt van de wereld.

UTC (Coordinated Universal Time) verving GMT als internationale standaard in 1972. UTC is gebaseerd op atoomklokken in plaats van astronomische observatie, waardoor het veel preciezer is. Voor de meeste praktische doeleinden tonen UTC en GMT dezelfde tijd, maar UTC is de correcte technische referentie.

Zomertijd: georganiseerde chaos

Ongeveer 70 landen hanteren zomertijd (DST), waarbij klokken in de lente een uur vooruit en in de herfst een uur achteruit worden gezet. Het doel is om wakkere uren af te stemmen op daglicht. Het resultaat is een halfjaarlijkse bron van bugs.

Belangrijke complicaties:

• Niet universeel. Het grootste deel van Afrika, Azië en Zuid-Amerika hanteert geen zomertijd. Binnen de VS doen Arizona en Hawaï niet mee.
• Verschillende data. De EU schakelt op de laatste zondag van maart en oktober. De VS schakelt op de tweede zondag van maart en de eerste zondag van november. Ze lopen meerdere weken per jaar niet synchroon.
• Ambigue tijden. Wanneer klokken teruggaan, komt het uur van 1:00 tot 2:00 tweemaal voor. Een timestamp van "1:30" op die dag is ambigu.
• Overgeslagen tijden. Wanneer klokken vooruitgaan, bestaat het uur van 2:00 tot 3:00 niet. Een vergadering gepland om 2:30 op die dag vindt nooit plaats.
• Politieke wijzigingen. Overheden kunnen (en doen dat) zomertijdregels op korte termijn wijzigen. Rusland ging in 2011 over op permanente zomertijd en schakelde in 2014 over op permanente standaardtijd. Marokko heeft de zomertijdregels meerdere keren gewijzigd.

ISO 8601: het universele datumformaat

Om dubbelzinnigheid te voorkomen definieert de internationale standaard ISO 8601 een duidelijk datum- en tijdformaat:

2026-03-29T14:30:00Z
2026-03-29T14:30:00+02:00
2026-03-29T14:30:00-05:00

• De T scheidt datum van tijd.
• Z betekent UTC (de "Zulu"-tijdzone in militaire terminologie).
• +02:00 of -05:00 is de UTC-offset.

Dit formaat is ondubbelzinnig, sorteerbaar als platte tekst en universeel begrepen door datumparsing-bibliotheken. Bij twijfel, gebruik ISO 8601.

Unix-timestamps

Een Unix-timestamp (ook wel epoch-tijd of POSIX-tijd genoemd) is het aantal seconden dat is verstreken sinds 1 januari 1970, 00:00:00 UTC — een moment dat bekendstaat als de Unix-epoch.

Unix-timestamps hebben geen tijdzone — ze zijn altijd in UTC. Dit maakt ze ideaal voor het opslaan en vergelijken van tijden in software. Je converteert naar een lokale tijdzone alleen op de presentatielaag.

De IANA-tijdzonedatabase

Software heeft niet alleen UTC-offsets nodig — het moet de volledige geschiedenis en toekomstige regels kennen voor elke regio, inclusief zomertijdovergangen, politieke wijzigingen en historische afwijkingen. Deze informatie bevindt zich in de IANA-tijdzonedatabase (ook wel de Olson-database of tzdata genoemd).

Het gebruikt identifiers zoals America/New_York, Europe/Paris, Asia/Tokyo. Elke vermelding codeert de volledige geschiedenis van UTC-offsets en zomertijdregels voor die locatie.

Daarom moet je nooit een tijdzone opslaan als een vast offset zoals "+02:00". Een offset vertelt je het huidige verschil met UTC maar zegt niets over zomertijdregels. Europe/Paris is UTC+1 in de winter en UTC+2 in de zomer. De IANA-identifier vangt beide.

Veelvoorkomende bugs in software

1. Lokale tijd opslaan zonder tijdzone. Een waarde als 2026-03-29 14:30:00 is betekenisloos zonder te weten naar welke tijdzone het verwijst. Sla altijd UTC op of neem de offset op.
2. Aannemen dat UTC-offset gelijk is aan tijdzone. UTC+2 in maart kan UTC+3 zijn in juli (als de regio zomertijd hanteert). Sla de IANA-identifier op, niet de offset.
3. DST-overgangen negeren bij planning. Een dagelijkse taak om 2:30 wordt één keer per jaar overgeslagen en één keer per jaar tweemaal uitgevoerd als je geen rekening houdt met zomertijd.
4. Aannemen dat dagen 24 uur hebben. Op zomertijdovergangsdagen heeft een dag 23 of 25 uur. "Morgen op dezelfde tijd" berekenen door 86.400 seconden op te tellen zal een uur afwijken.
5. JavaScript Date naïef gebruiken. new Date("2026-03-29") wordt in sommige engines als UTC geparsed en in andere als lokale tijd. Wees altijd expliciet over de tijdzone.

Best practices voor ontwikkelaars

• Sla tijden op in UTC. Converteer naar de lokale tijdzone van de gebruiker alleen op de presentatielaag.
• Gebruik IANA-tijdzone-identifiers (America/New_York), geen vaste offsets (-05:00).
• Gebruik ISO 8601 voor serialisatie. Het is ondubbelzinnig en universeel parseerbaar.
• Gebruik een volwassen datumbibliotheek. In JavaScript, gebruik Intl.DateTimeFormat of een bibliotheek zoals date-fns-tz. In Python, gebruik zoneinfo (3.9+) of pytz. In Java, gebruik java.time.ZonedDateTime.
• Houd tzdata bijgewerkt. Overheden wijzigen zomertijdregels. Je besturingssysteem en taalruntime hebben actuele tijdzonedata nodig.
• Test met meerdere tijdzones. Ga er niet vanuit dat je server en je gebruikers dezelfde zone delen.

Verder lezen

Tijd is bedrieglijk complex, maar de regels zijn goed gedocumenteerd en de tools zijn volwassen. De sleutel is de complexiteit te respecteren in plaats van weg te wuiven.

• Cron-expressies ontrafeld — taken plannen over tijdzones
• Hash-generator en Regex-tester — meer ontwikkelaarstools op ToolK