Tidsstempelformater: FILETIME, Unix, Apple og WebKit, og konvertering

Forside › Sikring: metoderne samlet · Gennemgået oktober 2026 · Af John Nielsen

Et tidsstempel i rå data er næsten altid et tal: antallet af tidsenheder siden et bestemt nulpunkt, en epoke. For at oversætte tallet til en dato skal man kende tre ting: epoken, enheden (sekunder, millisekunder, mikrosekunder eller 100 nanosekunder) og om værdien er i UTC eller lokal tid. Gætter man forkert på en af dem, får man en dato, der ser plausibel ud, men er forkert med år, timer eller faktorer af tusind. De fleste alvorlige tidsfejl i forensiske rapporter starter her.

Den grundlæggende forklaring af tidszoner findes på Tidsstempler og tidszoner, og metoden til at samle tider fra mange kilder i Tidslinjeanalyse. Her handler det kun om at læse tallet rigtigt. Omregning til én tidszone i rapporten står i UTC og sommertid i forensiske rapporter.

De almindelige formater

Windows FILETIME

Et 64-bit heltal, der tæller intervaller på 100 nanosekunder siden 1. januar 1601 kl. 00.00 UTC. Formatet bruges i NTFS-tidsstempler, registreringsdatabasen, hændelseslogs og mange andre Windows-artefakter. I rå hex gemmes det i little-endian, så bytes skal vendes, før tallet læses. En nutidig værdi har 18 cifre. Se NTFS i dybden.

Unix-tid

Antal sekunder siden 1. januar 1970 kl. 00.00 UTC, uden skudsekunder. Det er standard på Linux, i mange databaser, logs og API’er. Varianter i millisekunder (Java, JavaScript og mange apps), mikrosekunder og nanosekunder er udbredte, og feltet siger sjældent, hvilken enhed der er brugt. En nutidig værdi i sekunder har 10 cifre, i millisekunder 13, i mikrosekunder 16 og i nanosekunder 19.

Apple: Mac absolute time og HFS+

Apples Cocoa-tid tæller sekunder siden 1. januar 2001 kl. 00.00 UTC, ofte som et kommatal. Den bruges i mange databaser på iPhone og Mac. I nogle databaser er samme epoke brugt med nanosekunder i stedet for sekunder, også inden for samme app på tværs af versioner. En nutidig værdi i sekunder har 9 cifre. Det ældre filsystem HFS+ tæller sekunder fra 1. januar 1904. APFS bruger nanosekunder siden 1970. Hvilken enhed en given database bruger, kan skifte med en ny version af appen eller styresystemet, så antallet af cifre skal kontrolleres for hver database og hver version.

WebKit og Chrome

Chromium-baserede browsere gemmer mange tider som mikrosekunder siden 1. januar 1601 UTC, altså samme epoke som FILETIME, men en anden enhed. Firefox bruger PRTime, mikrosekunder siden 1970. Begge er 16-17 cifre lange og forveksles let. Se Browserhistorik som bevis.

FAT og DOS-tid

FAT-filsystemer på USB-nøgler og SD-kort gemmer dato og tid pakket i bitfelter i lokal tid uden angivelse af tidszone, med to sekunders opløsning for ændringstid og en epoke i 1980. exFAT har tilføjet felter for tidszoneforskydning og finere opløsning, men de bliver ikke altid udfyldt.

Dato som kommatal

Office-programmer og OLE Automation gemmer datoer som antal dage siden 30. december 1899, hvor decimaldelen er tidspunktet på dagen. Excel har desuden et 1904-datosystem fra ældre Mac-versioner, og arbejdsbøger kan bruge det ene eller det andet. En dato flyttet fire år og en dag er et tegn på forveksling.

Tekstformater

ISO 8601 (2025-03-14T09:30:00Z eller med +01:00) er entydigt, når forskydningen er med. Mailheadere bruger RFC 5322-formatet med forskydning. Logfiler skriver ofte tid som tekst uden tidszone, og så skal den udledes af systemets opsætning. Se Normalisering af logdata.

Sådan genkendes formatet

Antallet af cifre er det hurtigste fingerpeg for en nutidig dato:

9 · Apple-sekunder siden 2001
10 · Unix-sekunder
13 · Unix-millisekunder
16-17 · Unix- eller WebKit-mikrosekunder
18 · FILETIME eller Apple-nanosekunder
19 · Unix-nanosekunder

Fingerpeget skal altid bekræftes. Det mest pålidelige er en kendt hændelse: Lav en handling på et testsystem med samme app og version, notér tidspunktet, og find værdien i databasen. Eller find en post i samme tabel, hvis tidspunkt kendes fra en anden kilde, fx en besked, hvis modtagelse ses i en mailheader eller en serverlog.

Omregning mellem formaterne

Alle formaterne kan føres tilbage til Unix-sekunder med en fast forskydning og en division, og det gør det let at kontrollere et værktøjs konvertering i et regneark:

FILETIME: Divider med 10.000.000 for at få sekunder siden 1601, og træk 11.644.473.600 sekunder fra for at komme til 1970-epoken.
WebKit: Divider med 1.000.000, og træk derefter de samme 11.644.473.600 sekunder fra.
Apple-sekunder: Læg 978.307.200 sekunder til for at gå fra 2001 til 1970. Er værdien i nanosekunder, divideres først med 1.000.000.000.
Unix-millisekunder: Divider med 1.000.

Resultatet er UTC. Omregning til dansk tid sker som et separat, dokumenteret trin. Regneark har begrænset præcision på meget store tal, så FILETIME-værdier med 18 cifre kan miste de sidste cifre. Til de afgørende værdier bør der bruges et værktøj, der regner med heltal.

Typiske fejl ved konvertering

Forkert epoke: Apple-tid læst som Unix-tid giver en dato 31 år for tidligt. WebKit læst som Unix-mikrosekunder giver en dato 369 år forkert, hvilket er let at opdage. De små forskydninger er de farlige.
Forkert enhed: Millisekunder læst som sekunder giver en dato langt ude i fremtiden; det omvendte giver januar 1970.
Dobbelt konvertering til lokal tid: Værktøjet viser lokal tid, og analytikeren lægger en time til. Eller tiden var lokal i forvejen, og værktøjet behandler den som UTC.
Nulværdier: En tom værdi bliver 1. januar 1601 eller 1. januar 1970 ved konvertering. Det er ikke en hændelse, men et tomt felt.
Afrunding og kommatal: Kommatal i Apple-tid og regneark kan miste præcision. Afkortning til hele sekunder kan vende rækkefølgen af to tætte hændelser.
Fortegn og overløb: 32-bit Unix-tid løber over i 2038. Værdier læst som fortegnsløse eller med fortegn kan give meget forskellige datoer.
Byte-rækkefølge: Little-endian læst som big-endian giver meningsløse tal.

Kontrol af konverteringen

Brug mindst to uafhængige værktøjer på de tidsstempler, der bærer en konklusion, fx det forensiske værktøj og en separat dekoder eller et kontrolleret regneark. Kontrollér desuden mod en kendt hændelse i samme datakilde. Er der forskel mellem værktøjerne, skal den forklares, før tidsstemplet bruges. Afprøvning af værktøjer er beskrevet i Verifikation af forensiske værktøjer.

Hvad et konverteret tidsstempel kan og ikke kan bevise

Et korrekt konverteret tidsstempel viser, hvilken tid der er registreret i feltet, ifølge enhedens eller serverens ur på det tidspunkt. Det siger ikke, om uret gik rigtigt, og det siger ikke nødvendigvis, hvad feltet betyder. Et felt kaldet “date” i en app-database kan være afsendelse, modtagelse, læsning eller synkronisering. Feltets betydning skal afklares ud over formatet.

Dokumentation

Angiv for hver kilde i rapporten: feltets navn, rå værdi for de afgørende hændelser, det antagne format med epoke og enhed, hvordan formatet er bekræftet, og hvilken tidszone resultatet vises i. Med den rå værdi kan en modpart selv efterprøve konverteringen. Selve visningen af tidszoner og sommertid er beskrevet i Sommertid og tidszoner i rapporten.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Sikring: metoderne samlet

Læs også: Fuzzy hashing: når en fil næsten er den samme · Hvad sker der med tidsstemplerne ved kopiering, zip, upload og mail?

→ Forensisk sikring · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik