← Terug naar Kennisbank← Vorige vraagVolgende vraag →
ProgrammatieBackend ontwikkelaar, BI-analist

Leg uit hoe je tijdsgegevens en datumsintervallen in SQL verwerkt, wat zijn de kenmerken van tijdsfuncties (DATEDIFF, DATEADD, INTERVAL) in verschillende DBMS? Welke valkuilen kunnen zich voordoen bij het werken met tijdzones? Geef een voorbeeld van een correcte tijdsverschilberekening.

Slaag voor sollicitatiegesprekken met de Hintsage AI-assistent

Antwoord

In SQL zijn er veel functies voor het werken met datums en intervallen: DATEDIFF, DATEADD (T-SQL), werken met het type INTERVAL (PostgreSQL), functionaliteit voor tijdsconversie naar verschillende zones (AT TIME ZONE). Voor een correcte werking met datums is het belangrijk om datatypes te gebruiken die rekening houden met de tijdzone (TIMESTAMP WITH TIME ZONE, timestamptz), en niet alleen DATE of DATETIME, vooral voor wereldwijde diensten.

In verschillende DBMS varieert de syntaxis en de werkwijze:

  • SQL Server: DATEDIFF, DATEADD, FORMAT, maar geen volwaardig INTERVAL. Tijdzones worden expliciet geregeld.
  • PostgreSQL: ondersteuning voor INTERVAL, tal van functies (+/- INTERVAL), directe controle over tijdzones.

Fouten ontstaan vaak door inconsistentie in opslag in UTC/lokale tijd en het mengen van bewerkingen die deze verschillen niet in overweging nemen.

Voorbeeld van tijdsverschilberekening (PostgreSQL)

SELECT
  EXTRACT(EPOCH FROM (event_end AT TIME ZONE 'UTC' - event_start AT TIME ZONE 'UTC')) / 3600 AS hours
FROM events

Misleidende vraag

Kan DATEDIFF een negatieve waarde teruggeven, en wat betekent de volgorde van de datums?

Antwoord: Ja, DATEDIFF (DATEDIFF(day, d1, d2)) retourneert een negatief getal als d2 < d1. Het is belangrijk om de volgorde van de parameters niet te verwarren: eerst komt de eenheid van meting, dan de startdatum, en dan de einddatum.

Voorbeeld:

SELECT DATEDIFF(day, '2024-05-01', '2024-04-25') -- geeft -6 terug

Voorbeelden van echte fouten

Verhaal

In een project met wereldwijde gebruikers werden rapporten opgebouwd volgens de lokale tijd van servers in elke regio. Het resultaat — uit elkaar lopende aggregaten op datums en het ontstaan van "gaten" op de grens van middernacht voor gebruikers uit andere tijdzones. Dit werd opgelost door alle tijdsgegevens naar UTC te converteren en alleen voor weergave opnieuw te berekenen.

Verhaal

Bij het berekenen van de abonnementsduur met DATEDIFF was de volgorde van de datums verwisseld. Hierdoor werden sommige gebruikers ten onrechte als "supergebruikers" erkend met opzettelijk negatieve verjaring. Dit is opgelost door een controle in te voeren voor de volgorde van datums.

Verhaal

Een ontwikkelaar slaat DATETIME op zonder rekening te houden met de tijdzone, tijdens de migratie naar PostgreSQL werden de waarden geïnterpreteerd als UTC, terwijl ze oorspronkelijk in GMT+3 waren, wat leidde tot een verschuiving van gebeurtenissen in rapporten met 3 uur terug. Conclusie — altijd datums opslaan en omzetten met rekening houdend met de zone!