Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen
En forensisk rapport skal vise tidspunkter, som læseren ikke kan misforstå. Det kræver, at alle tider er omregnet til én tidszone, at tidszonen står ved hvert tidspunkt eller tydeligt i rapporten, og at overgangene til og fra sommertid er håndteret. Ellers kan en hændelse se ud til at ligge en time før eller efter en anden, og i natten, hvor sommertiden slutter, kan et lokalt klokkeslæt betyde to forskellige øjeblikke.
Den grundlæggende forklaring for ikke-teknikere findes på Tidsstempler og tidszoner. Denne artikel handler om, hvordan tiden præsenteres i rapporten. De øvrige tidsspørgsmål har egne artikler: hvilket ur der satte tiden i Server-tid og klient-tid, et forkert systemur i Urafvigelse, rå talformater i Tidsstempelformater, fildatoer ved kopiering i Hvad sker der med tidsstemplerne ved kopiering? og ensretning af logformater i Normalisering af logdata.
Dansk tid i praksis
Danmark bruger normaltid UTC+1 (CET) og sommertid UTC+2 (CEST). Sommertiden begynder den sidste søndag i marts, hvor uret stilles frem fra 02.00 til 03.00, og slutter den sidste søndag i oktober, hvor uret stilles tilbage fra 03.00 til 02.00. Begge skift sker kl. 01.00 UTC.
Det giver to særtilfælde:
- Den manglende time i marts: Lokale tider mellem 02.00 og 02.59 findes ikke. En logpost med lokal tid 02.30 den dag er enten en fejl eller skrevet af et system, der ikke har skiftet.
- Den dobbelte time i oktober: Lokale tider mellem 02.00 og 02.59 optræder to gange, først i sommertid og derefter i normaltid. En post med lokal tid 02.30 uden forskydning kan ikke placeres entydigt.
Dertil kommer, at tidspunkter fra andre lande skal omregnes med deres egne regler, og at reglerne har ændret sig historisk. Værktøjer bruger normalt IANA’s tidszonedatabase, hvor dansk tid hedder Europe/Copenhagen. Ældre eller dårligt vedligeholdte systemer kan have forkerte regler.
Valg af tidszone i rapporten
Der er to forsvarlige valg:
- UTC overalt: Entydigt og uden sommertidsproblemer. Godt til tekniske bilag og tidslinjer, der samler kilder fra flere lande. Ulempen er, at læseren skal regne om for at forstå hændelser i forhold til arbejdsdag og møder.
- Dansk lokaltid med forskydning: Fx 14.32.10 (+02:00). Lettere at læse for dommer og parter, og forskydningen gør tiden entydig, også i den dobbelte time.
Mange rapporter bruger begge: lokaltid med forskydning i hovedteksten og UTC i en kolonne i bilagene. Det afgørende er, at valget står tydeligt i indledningen, og at det følges konsekvent. Et tidspunkt uden tidszone bør ikke forekomme.
Normalisering trin for trin
- Fastlæg hver kildes oprindelige tidszone. Står den i data (UTC-markering, forskydning), noteres den. Står den ikke i data, udledes den fra systemets indstillinger, dokumentation eller en kendt hændelse.
- Konvertér til UTC som fælles grundlag.
- Konvertér derfra til præsentationstidszonen med en tidszonedatabase, ikke med en fast forskydning. En fast +1 eller +2 time giver fejl halvdelen af året.
- Bevar den rå værdi og den oprindelige tidszone ved siden af den normaliserede.
- Kontrollér overgangene: Find hændelser omkring sommertidsskift, og kontrollér, at de ligger rigtigt.
Normalisering af logkilder generelt er beskrevet i Normalisering af logdata, og de tekniske tidsformater i Tidsstempelformater.
Kilder uden tidszone
Tider i lokal tid uden forskydning er det store problem. Det gælder fx:
- FAT-filsystemer på USB-nøgler og SD-kort,
- mange tekstlogs fra servere, netværksudstyr og applikationer,
- tider i regneark og eksporter, hvor tidszonen er gået tabt,
- skærmbilleder af apps, der viser tid i telefonens indstillede tidszone.
For disse kilder skal den antagne tidszone dokumenteres sammen med begrundelsen. Ligger afgørende hændelser i den dobbelte time, må rapporten angive begge mulige tidspunkter, medmindre andre kilder kan afgøre det, fx en tilstødende post med forskydning eller sekventielle id’er, der viser rækkefølgen.
Sådan afgøres rækkefølgen i den dobbelte time
Når en afgørende hændelse ligger i den dobbelte time i en kilde uden forskydning, kan rækkefølgen ofte alligevel fastlægges:
- Sekventielle felter: Mange logs og databaser har løbenumre, record-id’er eller automatisk stigende nøgler. En post med et højere nummer er skrevet senere, uanset hvad klokkeslættet siger.
- Naboposter: Poster lige før og efter i samme kilde kan vise, om systemet allerede havde skiftet. Et spring tilbage i klokkeslættet mellem to poster med stigende løbenummer markerer skiftet.
- Andre kilder: En samtidig hændelse i en kilde med UTC, fx en cloudlog eller en mailheader med forskydning, kan placere den lokale post.
- Systemets egen log over tidsskift: Styresystemer registrerer ofte ændringer af systemtid og tidszone i en hændelseslog.
Kan rækkefølgen ikke afgøres, skal rapporten sige det. Det er bedre at angive to mulige tidspunkter end at vælge det ene uden grundlag. Det samme gælder, hvis to kilder har forskellig opløsning, og hændelserne ligger inden for samme sekund.
Overvej også, om spørgsmålet overhovedet afhænger af den time. Ofte er det afgørende, om noget skete før eller efter en dato eller et møde, og så er den dobbelte time uden betydning. Det bør stå i rapporten, så læseren ikke tillægger forbeholdet større vægt, end det har.
Værktøjernes visning
Forensiske værktøjer, regneark og logplatforme viser ofte tider i analytikerens egen tidszone eller i en tidszone, der er valgt i en indstilling. Det skaber tre typiske fejl:
- Dobbelt omregning: Værktøjet viser allerede lokal tid, og analytikeren lægger forskydningen til igen.
- Skjult omregning: En eksport til CSV fjerner tidszonen, så tider, der var UTC, læses som lokale.
- Skærmbilleder: Et skærmbillede fra et værktøj viser tider uden at angive, hvilken tidszone visningen er sat til.
Notér værktøjets tidszoneindstilling i arbejdsnoterne, og angiv den ved hvert skærmbillede i rapporten.
Tid fra flere lande
I sager med servere, cloudtjenester eller parter i andre lande skal det skelnes mellem, hvor hændelsen fandt sted, og hvor den blev registreret. En cloudtjeneste registrerer typisk i UTC, uanset hvor brugeren var. En telefon viser lokal tid efter sin indstilling, som kan følge netværket. Hvilken tid systemet faktisk viser, er beskrevet i Server-tid og klient-tid.
Præsentation
- Skriv tider ensartet, fx 2025-10-26 02.30.15 (+02:00), så sortering og læsning passer.
- Brug samme antal decimaler for sekunder i hele rapporten, og sig, hvor kilden har lavere opløsning.
- Markér hændelser i overgangsperioderne og forklar dem.
- Lad tidslinjegrafer vise tidszonen i aksen. Se Visualiseringer i forensiske rapporter.
Typiske fejlkilder
- Fast forskydning i stedet for tidszoneregler.
- Kilder uden tidszone behandlet som UTC.
- Hændelser i den dobbelte time placeret uden forbehold.
- Forskellige tidszoner i hovedtekst og bilag uden markering.
Hvad normaliseringen kan og ikke kan bevise
Korrekt normalisering gør det muligt at sammenligne tider fra forskellige kilder. Den retter ikke et forkert ur og afgør ikke, hvad et tidsstempel betyder. Afvigelser i selve urene er et separat spørgsmål, der skal undersøges og dokumenteres for sig. Se Tidslinjeanalyse.
Dokumentation
Rapportens metodeafsnit bør angive præsentationstidszonen, hver kildes oprindelige tidszone og hvordan den er fastlagt, den tidszonedatabase eller det værktøj, der er brugt til omregning, samt hvordan overgangene til og fra sommertid er behandlet.
Kilder og versioner
- IANA: Time Zone Database
- RFC 3339: Date and Time on the Internet: Timestamps
- EU-direktiv 2000/84/EF om sommertid (EUR-Lex)
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Sikring: metoderne samlet
Læs også: Hvad sker der med tidsstemplerne ved kopiering, zip, upload og mail? · Når enhedens ur går forkert: urafvigelse og korrektion
→ Forensisk sikring · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
