Hvad er Unix Epoch Time? En udviklervejledning til tidsstempler

Hvis du nogensinde har forespurgt en database eller arbejdet med en moderne API, har du sandsynligvis set datoer returneret ikke som "12. oktober 2026", men som en massiv, skræmmende række af tal som 1791800000. Dette er et Unix-tidsstempel, og det er den universelle rygrad i tidtagning inden for datalogi.

Håndtering af datoer og tidspunkter i programmering er notorisk vanskeligt. Tidszoner ændres, sommertid starter og stopper uforudsigeligt, og skudår introducerer ekstra dage. For at løse denne kaotiske virkelighed besluttede ingeniørerne, der byggede Unix-operativsystemet, at opfinde deres egen absolutte tidslinje.

Oprindelsen: 1. januar 1970

Et Unix-tidsstempel er simpelthen det antal sekunder, der er forløbet siden 1. januar 1970, kl. 00:00:00 UTC. Dette nøjagtige øjeblik i historien er kendt som "Unix-epoken".

Hvorfor 1970? For i begyndelsen af ​​1970'erne var opbevaringen utrolig dyr. Lagring af en dato som en menneskelig læsbar streng som "1970-01-01 00:00:00" optager næsten 20 bytes hukommelse. Lagring af det som et enkelt 32-bit heltal tog kun 4 bytes. Ved at tage udgangspunkt i det tidspunkt, Unix blev opfundet, maksimerede de mængden af ​​fremtidig tid, de kunne gemme inden for disse 4 bytes.

Hvorfor udviklere elsker Unix-tidsstempler

Den primære grund til, at Unix-tid er universelt vedtaget på tværs af API'er, databaser og mikrotjenester, er, at den ikke har nogen tidszone. Det repræsenterer et enkelt, absolut øjeblik i tiden globalt.

Hvis du gemmer en begivenhed i en database ved hjælp af lokal servertid ("03:00 PM EST") og senere migrerer din server til London, går al din matematik i stykker. Men hvis en hændelse finder sted ved tidsstempel 1700000000, er dette nummer identisk, uanset om brugeren, der forespørger, er i Tokyo, New York eller Paris. Frontend-applikationen tager simpelthen dette heltal og konverterer det matematisk til brugerens lokale tidszone på deres skærm.

Sekunder vs. Millisekunder (10 vs 13-cifret-reglen)

En af de mest almindelige fejl i webudvikling er at overføre et tidsstempel til en funktion og få en dato i år 1970 eller år 52.000. Dette sker på grund af en blanding mellem sekunder og millisekunder.

• Standard Unix-tid (sekunder): Et 10-cifret tal (f.eks. 1700000000). Dette er standarden i Linux, PHP og de fleste backend-databaser som MySQL.
• JavaScript-tid (millisekunder): Et 13-cifret tal (f.eks. 1700000000000). JavaScripts Date.now()-funktion inkluderer millisekunder for højere præcision.

Hvis du indlæser et 10-cifret backend-tidsstempel i JavaScript uden at gange det med 1000, antager JavaScript, at du taler om de første par dage af januar 1970.

// Correctly handling a Unix timestamp in JavaScript
const backendTimestamp = 1700000000;
const dateObject = new Date(backendTimestamp * 1000);

console.log(dateObject.toLocaleDateString()); // Converts to local user timezone

Året 2038-problemet (Y2K38)

Unix-tiden har en truende deadline. Fordi det oprindeligt blev gemt som et signeret 32-bit heltal, er det maksimale antal det kan indeholde 2.147.483.647.

Den 19. januar 2038, kl. 03:14:07 UTC, vil Unix-uret nå det maksimale antal. Et sekund senere vil hele tallet flyde over og vende til et negativt tal. Ældre systemer, der ikke er blevet opgraderet til 64-bit arkitektur, vil pludselig tro, at året er 1901, hvilket forårsager katastrofale fejl i software verden over.

Heldigvis er næsten al moderne hardware, databaser og programmeringssprog (som 64-bit Linux-kerner og moderne Node.js) allerede gået over til 64-bit tid, hvilket skubber det næste overløb milliarder af år ud i fremtiden.

Ofte stillede spørgsmål (FAQ)