Tidszonstesta AI-genererad kod: fem fall som går sönder vid midnatt

Börja med att namnge vilken sorts tid du har

AI-genererad kod blandar ofta ihop fyra värden som ser nästan likadana ut: exakt tid i UTC, lokal klocktid utan zon, kalenderdatum utan klockslag och tidszonsbunden tid som kombinerar en exakt tid med reglerna för exempelvis Europe/Stockholm. Felet uppstår när koden konverterar mellan dem utan att kravet säger hur. Börja i den bredare guiden till testning av AI-genererad kod om klocka, beroenden och testmiljö ännu inte går att styra.

Texten ”mötet börjar 09.00 i Stockholm den 15 oktober” är inte färdiglagrad som en exakt tid förrän zonreglerna har använts. Texten ”jobbet kördes 07:00Z” är däremot en exakt tidpunkt men säger inget om vilket lokalt datum en användare såg. Och ”fakturadatum 2026-08-11” ska ofta förbli ett datum; att göra det till midnatt UTC kan flytta det till dagen före i Amerika.

Gör klockan och zonen till testdata

Testet får inte fråga datorn vad klockan är eller ärva utvecklarens tidszon. Skicka in ”nu” och zonen som beroenden. Då blir samma test grönt i Stockholm, på CI-servern och hos kollegan.

export function localOrderDate({ now, timeZone, toLocalDate }) {
  return toLocalDate(now, timeZone);
}

test('orderns datum bestäms i kundens zon', () => {
  const now = '2026-08-11T22:30:00Z';
  assert.equal(localOrderDate({
    now,
    timeZone: 'Europe/Stockholm',
    toLocalDate
  }), '2026-08-12');
});

toLocalDate ska vara den tidszonsfunktion produktionen faktiskt använder. Undvik en hemmabyggd offsettabell. I modern JavaScript ger Temporal separata typer för bland annat Instant, PlainDate och ZonedDateTime, men kontrollera stöd eller vald polyfill i just din runtime.

Fall 1: den lokala tiden finns inte

När sommartid börjar kan klockan hoppa framåt. En lokal tid mitt i hoppet har ingen motsvarande exakt tidpunkt. Testet ska inte nöja sig med att biblioteket ”löser” situationen; det ska uttrycka produktbeslutet.

const input = {
  timeZone: 'Europe/Stockholm',
  year: 2026, month: 3, day: 29, hour: 2, minute: 30
};

assert.throws(
  () => Temporal.ZonedDateTime.from(input, { disambiguation: 'reject' }),
  RangeError
);

För en bokning är ”be användaren välja en giltig tid” ofta bättre än att tyst flytta mötet. För ett nattligt underhållsjobb kan ”kör vid första giltiga tid efter hoppet” vara rätt. Båda är legitima krav, men de kräver olika förväntningar i testet.

Fall 2: samma klockslag inträffar två gånger

När klockan ställs tillbaka kan exempelvis 02.30 förekomma två gånger med olika offset. Om en användare väljer lokal tid måste systemet antingen fråga, välja en dokumenterad regel eller avvisa tvetydigheten.

const repeated = {
  timeZone: 'Europe/Stockholm',
  year: 2026, month: 10, day: 25, hour: 2, minute: 30
};

const first = Temporal.ZonedDateTime.from(repeated, {
  disambiguation: 'earlier'
});
const second = Temporal.ZonedDateTime.from(repeated, {
  disambiguation: 'later'
});

assert.equal(second.epochMilliseconds - first.epochMilliseconds, 3_600_000);

Lägg dessutom in ett test för hur tiden visas efter laddning. Om databasen bara sparar strängen 2026-10-25 02:30 går det inte att veta vilket tillfälle som avsågs. En exakt tidpunkt plus zon-ID kan återge både ordningen och användarens lokala sammanhang.

Fall 3: UTC-datumet är inte användarens datum

Vid midnatt blir en enkel toISOString().slice(0, 10) ofta en produktbugg. Metoden ger UTC-datumet, inte kundens, kontorets eller avtalets lokala datum. Välj en exakt tid som ligger på olika kalenderdagar i två zoner och testa båda.

const instant = Temporal.Instant.from('2026-08-11T22:30:00Z');

assert.equal(
  instant.toZonedDateTimeISO('Europe/Stockholm').toPlainDate().toString(),
  '2026-08-12'
);
assert.equal(
  instant.toZonedDateTimeISO('America/New_York').toPlainDate().toString(),
  '2026-08-11'
);

Bestäm vilken zon som äger affärsdatumet. En användarvy kan följa användaren, medan bokföringsdagen kan följa bolagets beslutade zon. Koden ska inte välja efter serverns miljövariabel av misstag.

Fall 4: nästa dag är inte alltid 24 timmar senare

”Samma tid i morgon” är kalenderaritmetik. ”Efter 24 timmar” är en varaktighet på den exakta tidslinjen. Vid en offsetförändring kan resultaten skilja sig med en timme.

const start = Temporal.ZonedDateTime.from(
  '2026-03-28T12:00:00+01:00[Europe/Stockholm]'
);

const sameLocalTimeTomorrow = start.add({ days: 1 });
const exactly24HoursLater = start.add({ hours: 24 });

assert.equal(sameLocalTimeTomorrow.hour, 12);
assert.equal(exactly24HoursLater.hour, 13);

Använd kalenderdag för exempelvis ”påminn klockan 12 nästa dag”. Använd timmar för ”token löper ut efter exakt 24 timmar”. Be AI-assistenten skriva kravet i ord innan den ändrar implementationen.

Fall 5: framtida zonregler kan ändras

IANA:s tidszonsdatabas uppdateras när länder ändrar regler och när historiska uppgifter korrigeras. Vid kontrollen den 11 augusti 2026 var senaste publicerade versionen 2026c. Ett framtida möte kan därför få en annan UTC-tid efter en tzdb-uppdatering även om avsikten ”09.00 lokal tid” är oförändrad.

Testa uppgraderingen som en datamigrering, inte bara som en biblioteksuppdatering. Välj framtida poster, beräkna dem med den gamla och nya zondata som era miljöer faktiskt använder och klassificera skillnaderna. Systemet behöver ett produktbeslut: ska den exakta tidpunkten ligga fast, ska den lokala klocktiden ligga fast eller ska användaren informeras?

Beställ fem tester utan att be AI gissa kravet

Granska datum- och tidskoden nedan. Ändra ingen kod ännu.

1. Klassificera varje värde som exakt tid, lokal klocktid,
   kalenderdatum eller tidszonsbunden tid.
2. Lista var systemets tidszon eller aktuella klocka läses implicit.
3. Föreslå ett reproducerbart test för:
   - en saknad lokal timme,
   - en upprepad lokal timme,
   - en UTC-tid som ger olika lokala datum,
   - samma lokala tid nästa dag jämfört med 24 timmar senare,
   - en framtida tid vars zonregel kan ändras.
4. Skriv förväntat verksamhetsbeteende som en fråga där kravet saknas.
5. Ange vilken runtime och version testexemplet förutsätter.

Godkänn inte ett test som bara duplicerar implementationen. Förväntningen ska komma från ett beslutat beteende och använda kända tidpunkter. Kör gärna samma svit med processens standardzon satt till både UTC och Europe/Stockholm; resultatet ska vara identiskt om alla beroenden är explicita.

En liten releasegrind för datumkod

Kombinera grinden med mutationstestning av AI-genererade tester: flytta ett gränsvärde, ta bort zonen eller byt kalenderdag mot 24 timmar och kontrollera att rätt test faktiskt faller.