Gedurende mijn carrière heb ik al veel IT’ers hun tanden kapot zien bijten op datum en tijdbewerkingen. Zelfs de grote jongens als Apple maken af en toe al eens een foutje als het gaat over het terug of vooruit schakelen van de klok. Op 31 maart 2019 is het opnieuw zover. Benieuwd wie het nieuws zal halen met een onfortuinlijke zomertijd-bug.

Niet IT’ers kunnen weinig of zelfs geen begrip opbrengen aangaande de verborgen complexiteit van datum en tijd. Het lijkt een simpele materie. En, dat is meteen ook één van de belangrijkste oorzaken waarom er vaak fouten worden gemaakt bij datum en tijdberekeningen.

Ernaast geschoten

Het mag een schrale troost zijn dat deze problematiek niet nieuw is. Door het gebruik van de Juliaanse kalender arriveerde het Russische Olympische schuttersteam liefst 12 dagen te laat op de Olympische spelen in Londen in 1908. Niemand die toen stilstond dat Londen de Gregoriaanse kalender gebruikte.

Cloud klaart de mist op

Cloud Software maakt de complexiteit plots meer zichtbaar. De tijd dat software werd ontwikkeld, getest en uitgerold op een server die in precies dezelfde tijdszone stond, is ondertussen voorbij. Klanten en medewerkers willen 24/7 gebruik maken van de software platformen, ongeacht waar ze zich bevinden, op kantoor, thuis of op een exotische bestemming.

Tijdszones zijn vervelend omdat we nu eenmaal niet gewend zijn om tijd te zien binnen de context van een tijdszone. We denken: ‘het is 3 uur op 30 maart 2019’, eerder dan het is 6 uur later dan UTC, of het is GMT + 1 uur, of het is 22 uur in Shanghai. Nochtans zijn het allemaal valabele manieren om precies dezelfde tijd aan te geven.

Precies dezelfde vraag stellen een dag later, na het overschakelen op de zomertijd, zal menig wenkbrauw doen fronsen. Want eerlijk, weet jij of Shanghai morgen op 31 maart overschakelt naar het zomeruur? Voilà, I made my point. Dus vanaf nu graag wat meer begrip voor de IT’er die het hoofd moet bieden aan deze complexe materie.

Zulu

Bij de bouw van een software systeem zijn volgende begrippen belangrijk: de tijd en tijdzone waar de gebruiker zich bevindt, de tijd en tijdzone waar de server staat en UTC.

UTC staat voor Universal Coordinated Time. Eigenlijk is het geen afkorting maar een compromis tussen tussen het Franse ‘TUC’ (Temps universel coordonné) en het Engelse ‘CUT’ (Coordinated Universal Time). In militaire kringen wordt ‘Zulu time’ gebruikt. Toegegeven, het bekt beter en stoerder dan UTC maar het is precies hetzelfde.

Belangrijk te weten is dat UTC geen tijdzone is. Tijdzones worden uitgedrukt als een offset t.o.v. UTC. Dankzij Arthur David Olson bestaat er zoiets als de Olson database (ook tz database genoemd) dewelke alle relevante informatie over tijdzones en zomertijden bijhoudt. Gebruik je als programmeur de ingebouwde tijd en datumfuncties van je technologiestack, dan is de kans reëel dat deze gebaseerd zijn op de gegevens uit de Olson databank.

Goede programmeurs wagen zich trouwens niet aan eigen geschreven tijd en datumroutines: hoe laat is het 1 minuut later dan 01:59? Meestal 02:00, maar soms 03:00. Welke dag komt na 28 februari? Meestal 1 maart, maar soms ook al eens 29 februari. Zomaar eventjes 365 bij een datum tellen om ‘deze dag volgend jaar’ te berekenen, is helemaal uit den boze. Bezint eer ge begint.

Een andere misconceptie is dat datums geen tijdzone indicatie hoeven. Terwijl ik dit schrijf, is het in Sydney reeds een dag later. Veronderstel dat ik op 31 mei (lokale tijd in België) iets online bestel op een server die in Sydney staat (1 juni), wat is dan de datum van mijn bestelling? Of stel dat ik een leverdatum specificeer, … zonder tijdzone indicatie loopt dit gegarandeerd mis.

Kwestie van aanpak

Het is een goede gewoonte om van meet af aan de omgeving waarin ontwikkeld en getest wordt in verschillende tijdzones in te richten. Wanneer de ontwikkelaar, de cloudinfrastructuur en de testers zich in andere tijdzones bevinden, komen eventuele tijd gerelateerde bugs onmiddellijk naar boven.

Uw gebruikers zullen uw eeuwig dankbaar zijn.