Varför din AI-byggda app visar fel tid (och hur du fixar tidszoner)

Varför visar en AI-byggd app fel tid?

Eftersom två personer på olika platser båda kan titta på rätt tid och se två olika siffror — den missmatchningen är hela tidszonsproblemet. En kund i Madrid bokar din tid 15:00; du är i Mexico City, och din skärm visar samma bokning klockan 08:00. Du stirrar på den, säker på att något är trasigt.

Inget är trasigt. Klockan är 15:00 i Madrid och 08:00 i Mexico City i exakt samma ögonblick. Ni har båda rätt. Det gapet — där två personer som båda har rätt ser två olika siffror — ligger bakom ett förvånansvärt stort antal buggrapporter av typen “min app beter sig konstigt”.

Det smyger sig på dig eftersom du under byggande och testning är den enda personen, på en plats, på en enhet. Allt stämmer. Tidszoner visar bara sina tänder när en andra person, någon annanstans, tittar på samma tid. Om din app har användare i mer än en stad — eller skickar någon typ av schemalagt meddelande — kommer det här ikapp dig. Bäst att möta det med flit.

Vad är egentligen en tidszon?

En tidszon är “plats”-halvan av en tid — den del som omvandlar ett universellt ögonblick till en lokal klockavläsning. Här är den enda idén som gör resten begripligt: varje tidpunkt har två delar.

1. Ögonblicket — ett specifikt tillfälle som är detsamma överallt på jorden.
2. Platsen — var du befinner dig när du läser av klockan.

“15:00” i sig betyder ingenting. 15:00 var? Datorer hanterar detta genom att lagra ögonblicket i ett neutralt, platslöst format (du kommer att höra din byggare säga “UTC” — tänk på det som klockan vid en fast referenspunkt), och sedan visa det i varje persons lokala tid när de tittar.

När en app visar fel tid beror det nästan alltid på att den tappat bort en av de här två delarna — den glömde platsen, eller så lagrade den aldrig ett riktigt ögonblick från början.

Vad orsakar tidszonsbuggar i appar?

Tre specifika misstag orsakar nästan alla tidszonsbuggar: att lagra en klockavläsning istället för ett riktigt ögonblick, att visa serverns tidszon istället för användarens, och att ignorera skiften för sommartid.

1. Appen lagrar en klockavläsning, inte ett ögonblick. Någon väljer “09:00” och appen sparar texten “09:00” utan någon plats kopplad till den. Nu visar den “09:00” för alla, överallt, vilket ibland är precis vad du vill (en medicinpåminnelse som ska utlösas klockan 9 på förmiddagen lokalt för varje person) och ibland en katastrof (ett live-webbinarium som ska starta vid exakt ett ögonblick för alla). Om appen gissar fel på vilket av dem du menade glider tiden iväg.

2. Appen visar serverns tid, inte användarens. Din app körs på en dator i ett datacenter — säg Virginia. Om ingen sa något annat visar den gladeligen Virginias tid för alla. Dina användare i London ligger nu en eftermiddag fel och har ingen aning om varför.

3. Sommartid flyttar klockorna och din app märker det inte. Två gånger om året ställer många platser om sina klockor en timme. Ett återkommande möte “varje tisdag klockan 09:00” som du satte upp på vintern hamnar plötsligt klockan 08:00 eller 10:00 på sommaren om appen låste sig vid en fast tidsskillnad istället för en plats.

Tre verkliga versioner av det här

Eventet som startade tre gånger. En grundare byggde en enkel sida för en onlineworkshop med en starttid utskriven: “Startar 18:00.” Deltagare i tre länder läste var och en “18:00” som sin egen lokala 18:00. En tredjedel av dem anslöt en timme sent, några anslöt en timme tidigt, och alla skyllde på länken. Fixen var inte en bättre länk — det var att visa varje person deras egen lokala starttid, med tidszonen utskriven.

Nyhetsbrevet som kom klockan 02:00 på natten. Ett mejl som skulle “skickas varje morgon klockan 08:00” gick ut klockan 08:00 på servern. För den europeiska halvan av listan var det mitt i natten. Öppningsfrekvensen för de prenumeranterna var uselt, och det såg ut som ett innehållsproblem. Det var ett tidszonsproblem.

Den dubbelbokade söndagen. En bokningsapp lät två personer reservera samma massagetid natten då klockorna “ställdes tillbaka”, eftersom 01:30 inträffade två gånger den natten och appen behandlade dem som samma ögonblick. Sällsynt, men det är den typen av bugg som kostar dig en riktig kund och en riktig ursäkt.

Vad ska du be din byggare fixa när det gäller tidszoner?

Be om fyra specifika saker, i vardagligt språk — du behöver inte lära dig något av det här i detalj. Kopiera dessa:

“Lagra varje tid som ett UTC-ögonblick, och lagra även varje användares tidszon.”

“När du visar en tid, visa den i betraktarens tidszon, och skriv ut zonen precis bredvid — som 15:00 (din tid) eller 15:00 CET.”

“För allt som återkommer — påminnelser, scheman, återkommande events — förankra det till en plats (som ‘America/Mexico_City’), inte till ett fast antal timmar, så att sommartid hanteras automatiskt.”

“Låt mig testa det som om jag befann mig i ett annat land.”

Den sista punkten spelar större roll än den låter, vilket för oss till den del du kan göra själv.

Hur testar du din app för tidszonsbuggar?

Du kan fånga de flesta tidszonsbuggar på två minuter utan en användare i ett annat land — låtsas bara att du är i ett:

1. Öppna datum- och tidsinställningarna på din telefon eller dator och byt tidszon till någonstans långt bort — Tokyo, London, var som helst.
2. Ladda om din app.
3. Titta på varje ställe en tid dyker upp. Stämmer den fortfarande? Talar den om vems tid det är?

Om en bokning som borde vara klockan 15:00 nu visar 04:00 på natten utan förklaring har du hittat en bugg innan en kund gjorde det. Byt tillbaka dina inställningar när du är klar. För fallen med återkommande påminnelser och sommartid är det säkraste testet att be en vän i ett annat land titta på ett enda datum och berätta vilken tid de ser.

Behöver du ens bry dig om tidszoner?

Ärligt talat — ibland inte, och det är värt att säga. Om varje enskild person som använder din app befinner sig i samma stad — ett lokalt restaurangschemaläggningsverktyg för personalen, en anmälningslista för en grannskapsklubb — kan du mestadels hoppa över de svåra delarna. Var bara konsekvent och märk tiden så att det inte råder något tvivel.

Tidszoner blir en verklig fråga i samma stund som en av två saker gäller: två personer på olika platser delar en tid, eller din app skickar något enligt ett schema. I samma ögonblick du korsar den gränsen är den billigaste försäkringen också den enklaste: visa alltid tidszonen bredvid tiden. Den enda vanan tar bort den oklarhet som orsakar de flesta av de här historierna, redan innan de djupare fixarna är på plats.

Så nästa gång du lägger till ett datum- eller tidsfält i din app, ställ en fråga till dig själv innan du går vidare: vems tid är det här? Om du kan svara på det högt är du redan före de flesta appar folk bygger.