Waarom je AI-gebouwde app de verkeerde tijd toont (en hoe je tijdzones oplost)

Waarom toont een AI-gebouwde app de verkeerde tijd?

Omdat twee mensen op verschillende plekken allebei naar de juiste tijd kunnen kijken en toch twee verschillende getallen zien — die mismatch is het hele tijdzoneprobleem. Een klant in Madrid boekt jouw slot van 15:00 uur; jij zit in Mexico-Stad, en op je scherm staat diezelfde boeking om 8:00 uur ‘s ochtends. Je staart ernaar, ervan overtuigd dat er iets stuk is.

Er is niets stuk. Het is tegelijkertijd 15:00 uur in Madrid en 8:00 uur ‘s ochtends in Mexico-Stad. Jullie hebben allebei gelijk. Dat gat — waarin twee mensen die allebei gelijk hebben twee verschillende getallen zien — zit achter een verrassend groot aantal bugmeldingen van “mijn app doet raar”.

Het sluipt erin omdat je tijdens het bouwen en testen de enige persoon bent, op één plek, op één apparaat. Alles klopt. Tijdzones laten pas hun tanden zien zodra een tweede persoon, ergens anders, naar dezelfde tijd kijkt. Als je app gebruikers in meer dan één stad heeft — of ook maar één soort geplande bericht verstuurt — dan komt dit vroeg of laat op je pad. Beter om het bewust tegemoet te treden.

Wat is een tijdzone precies?

Een tijdzone is de “plaats”-helft van een tijd — het stukje dat één universeel moment omzet in een lokale klokstand. Hier is het ene idee dat de rest logisch maakt: elke tijd bestaat uit twee delen.

1. Het moment — één enkel ogenblik dat overal op aarde hetzelfde is.
2. De plaats — waar jij bent op het moment dat je de klok afleest.

“15:00 uur” op zichzelf betekent niets. 15:00 uur waar? Computers lossen dit op door het moment op te slaan in een neutraal, plaatsloos formaat (je zult je bouwer “UTC” horen zeggen — zie het als de klok op een vast referentiepunt), en het pas te tonen in ieders lokale tijd op het moment dat diegene ernaar kijkt.

Wanneer een app de verkeerde tijd toont, is dat vrijwel altijd omdat die een van die twee delen kwijt is geraakt — de plaats is vergeten, of er is nooit een echt moment opgeslagen om mee te beginnen.

Wat veroorzaakt tijdzonebugs in apps?

Drie specifieke fouten veroorzaken bijna elke tijdzonebug: een klokstand opslaan in plaats van een echt moment, de tijdzone van de server tonen in plaats van die van de gebruiker, en zomertijdverschuivingen negeren.

1. De app slaat een klokstand op, geen moment. Iemand kiest “9:00 uur” en de app slaat de tekst “9:00 uur” op zonder plaats erbij. Nu toont die “9:00 uur” aan iedereen, overal, wat soms precies is wat je wilt (een medicijnherinnering die om 9 uur lokale tijd moet afgaan voor elke persoon) en soms een ramp (een live webinar dat voor iedereen op exact hetzelfde moment moet beginnen). Als de app verkeerd raadt welke van de twee je bedoelde, loopt de tijd uit de pas.

2. De app toont de tijd van de server, niet die van de gebruiker. Je app draait op een computer in een datacenter — zeg, Virginia. Als niemand haar anders heeft verteld, toont ze iedereen vrolijk de tijd van Virginia. Je gebruikers in Londen zitten er nu een middag naast en hebben geen idee waarom.

3. Zomertijd verzet de klokken en je app merkt het niet. Twee keer per jaar verzetten veel plekken hun klokken een uur. Een terugkerende afspraak “elke dinsdag om 9:00 uur” die je ‘s winters hebt ingesteld, staat plotseling op 8:00 of 10:00 uur in de zomer als de app zich had vastgezet op een vaste tijdsverschuiving in plaats van op een plaats.

Drie echte versies van dit verhaal

Het evenement dat drie keer begon. Een oprichter bouwde een simpele pagina voor een online workshop met daarop één begintijd: “Start om 18:00 uur.” Deelnemers in drie landen lazen “18:00 uur” elk als hun eigen lokale 18:00 uur. Een derde van hen kwam een uur te laat, een paar kwamen een uur te vroeg, en iedereen gaf de link de schuld. De oplossing was geen betere link — het was iedereen hun eigen lokale begintijd tonen, met de tijdzone er expliciet bij.

De nieuwsbrief die om 2 uur ‘s nachts aankwam. Een e-mail die “elke ochtend om 8:00 uur” moest worden verstuurd, ging om 8:00 uur op de server de deur uit. Voor het Europese deel van de lijst was dat midden in de nacht. De openingspercentages voor die abonnees waren belabberd, en het leek een contentprobleem. Het was een tijdzoneprobleem.

De dubbel geboekte zondag. Een boekingsapp liet twee mensen hetzelfde massageslot reserveren op de nacht dat de klokken “terug” gingen, omdat 1:30 uur die nacht twee keer voorkwam en de app dat als hetzelfde moment behandelde. Zeldzaam, maar het is precies het soort bug dat je een echte klant en een echte verontschuldiging kost.

Wat moet je je bouwer vragen om tijdzones te fixen?

Vraag om vier specifieke dingen, in gewone taal — je hoeft hier zelf geen detailkennis van te hebben. Kopieer deze:

“Sla elke tijd op als een UTC-moment, en sla ook de tijdzone van elke gebruiker op.”

“Toon een tijd altijd in de tijdzone van de kijker, en zet de zone er direct naast — zoals 15:00 uur (jouw tijd) of 15:00 uur CST.”

“Koppel alles wat zich herhaalt — herinneringen, roosters, terugkerende evenementen — aan een plaats (zoals ‘America/Mexico_City’), niet aan een vast aantal uren, zodat zomertijd automatisch wordt afgehandeld.”

“Laat me het testen alsof ik in een ander land zit.”

Dat laatste punt is belangrijker dan het klinkt, en daarmee komen we bij het deel dat je zelf kunt doen.

Hoe test je je app op tijdzonebugs?

Je vangt de meeste tijdzonebugs in twee minuten zonder een gebruiker in een ander land nodig te hebben — doe gewoon alsof je er zelf een bent:

1. Open de datum-en-tijdinstellingen van je telefoon of computer en zet de tijdzone op iets ver weg — Tokio, Londen, maakt niet uit.
2. Herlaad je app.
3. Bekijk elke plek waar een tijd getoond wordt. Klopt het nog steeds? Staat erbij van wie die tijd is?

Als een boeking die om 15:00 uur zou moeten zijn nu 4:00 uur ‘s ochtends toont zonder uitleg, heb je een bug gevonden voordat een klant dat deed. Zet je instellingen terug zodra je klaar bent. Voor de gevallen met terugkerende herinneringen en zomertijd is de zekerste check om één vriend in een ander land naar een specifieke datum te laten kijken en te vragen welke tijd diegene ziet.

Moet je je überhaupt zorgen maken over tijdzones?

Eerlijk gezegd — soms niet, en dat is de moeite waard om te zeggen. Als elke persoon die je app gebruikt in dezelfde stad zit — een personeelsplanningstool voor een lokaal restaurant, een inschrijflijst voor een buurtclub — dan kun je de lastige onderdelen grotendeels overslaan. Wees gewoon consistent en label de tijd zodat er geen twijfel bestaat.

Tijdzones worden een echt aandachtspunt zodra een van deze twee dingen waar is: twee mensen op verschillende plekken delen een tijd, of je app verstuurt iets volgens een schema. Zodra je die grens overschrijdt, is de goedkoopste verzekering ook de simpelste: toon de tijdzone altijd naast de tijd. Die ene gewoonte haalt de ambiguïteit weg die de meeste van deze verhalen veroorzaakt, nog voordat de diepere oplossingen er zijn.

Dus de volgende keer dat je een datum- of tijdveld aan je app toevoegt, stel jezelf dan één vraag voordat je verdergaat: van wie is deze tijd? Als je die vraag hardop kunt beantwoorden, loop je al voor op de meeste apps die mensen bouwen.