Hva er et Unix-tidsstempel? Den komplette guiden
Et Unix-tidsstempel er antall sekunder som har gått siden 1. januar 1970 klokken 00:00:00 UTC, kjent som Unix-epoken. Det er tallet du finner i en created_at-kolonne i en database, i et API-svar, eller i exp-feltet på en JWT. Én enkelt dato og ett klokkeslett, hvor som helst på kloden, blir dermed representert av ett eneste heltall.
Hva et Unix-tidsstempel egentlig er
I stedet for å lagre en dato som tekst, for eksempel «14. november 2023, 22:13:20», teller Unix-tidsstemplet sekunder fra et fast referansepunkt. 1. januar 1970 ble valgt da Unix-systemet ble designet, og har siden blitt en de facto standard langt utover selve Unix.
Grunnen til at datamaskiner foretrekker denne løsningen fremfor en formatert tekststreng, er enkel: et heltall er kompakt, det er entydig, og det er uavhengig av tidssone. En tekststreng som «14/11/2023» kan bety 14. november eller november det 11., avhengig av hvem som leser den, og sier ingenting om hvilken tidssone klokkeslettet gjelder for. Et tidsstempel som 1700000000 betyr nøyaktig det samme øyeblikket uansett hvor på jorda du befinner deg, og lar en database sortere, sammenligne og regne på datoer med vanlig heltallsaritmetikk i stedet for å måtte parse tekst hver gang.
Det er derfor loggfiler, databaser og API-er som regel lagrer tidspunkter som tidsstempler internt, og først formaterer dem til noe lesbart når de skal vises til et menneske.
Eksempel: å lese ekte tidsstempelverdier
Tabellen under viser fem konkrete tidsstempler og hva de faktisk tilsvarer i UTC:
| Unix-tidsstempel (sekunder) | Dato og klokkeslett i UTC |
|---|---|
| 0 | 1. januar 1970, kl. 00:00:00 UTC (selve epoken) |
| 1000000000 | 9. september 2001, kl. 01:46:40 UTC |
| 1700000000 | 14. november 2023, kl. 22:13:20 UTC |
| 2000000000 | 18. mai 2033, kl. 03:33:20 UTC |
| 2147483647 | 19. januar 2038, kl. 03:14:07 UTC |
Ta 1700000000 som eksempel. Det tallet representerer 1,7 milliarder sekunder etter midnatt 1. januar 1970. Del det på sekundene i et år (omtrent 31,5 millioner) og du havner rundt 54 år frem i tid, altså rett i overkant av 2023. At det lander på 14. november klokken 22:13:20 UTC helt presist, er ikke noe du regner ut i hodet, men det er nettopp derfor tabellen er nyttig å ha ved siden av seg: den samme verdien dukker for øvrig opp igjen som eksempel i seksjonene under, siden 1700000000 er akkurat den typen created_at-verdi du ville støtt på i en ekte databaserad.
Legg også merke til hvor spesiell den siste raden er. 2147483647 er ikke et tilfeldig valgt tall, det er den høyeste verdien et 32-bits signert heltall kan lagre, og det kommer vi tilbake til lenger ned.
Sekunder eller millisekunder? Slik skiller du dem
Den klassiske fellen med Unix-tidsstempler er å blande sammen sekunder og millisekunder. I dag har et tidsstempel i sekunder 10 siffer, for eksempel 1700000000. Det samme øyeblikket i millisekunder har 13 siffer: 1700000000000, fortsatt 14. november 2023.
Hvorfor har begge formatene overlevd side om side? JavaScripts Date.now() og mange nettleser- og web-API-er returnerer millisekunder, siden det gir finere presisjon i klientkode. Unix-systemkall, cron, og det meste av tradisjonelt Unix- og Linux-verktøy, bruker derimot sekunder, siden det er det opprinnelige formatet operativsystemet selv ble bygget rundt.
Konsekvensen av å blande de to er konkret og ganske morsom å se skje: limer du inn en verdi i millisekunder i et felt som forventer sekunder, multipliserer du datoen med 1000 uten å mene det, og havner et sted langt inn i fremtiden i stedet for i 2023. Det er en av de vanligste feilene når man feilsøker et API-svar eller en created_at-kolonne som plutselig viser en dato om flere tusen år.
Konverter et tidsstempel til en dato
Har du et tall du stirrer på i en loggfil eller en databaserad og lurer på hvilken dato det egentlig er? Lim det inn under, så får du svaret umiddelbart, i UTC og i din egen lokale tid.
Konverter en dato til et tidsstempel
Den motsatte oppgaven dukker opp minst like ofte. Skal du planlegge en cron-jobb til et bestemt tidspunkt, sette utløpstiden i et API-kall, eller skrive en fast dato inn i en spørring mot databasen, trenger du det som tidsstempel, ikke som tekst.
Vanlige feil og spesialtilfeller
Å blande sammen sekunder og millisekunder. Dette er dekket i detalj over, men det er verdt å nevne igjen som den desidert vanligste feilkilden: sjekk sifferantallet (10 for sekunder, 13 for millisekunder) før du limer en verdi inn i et system som forventer det ene eller det andre.
År 2038-problemet. Systemer som lagrer tidsstempelet som et 32-bits signert heltall, når den øvre grensen sin ved nøyaktig 2147483647, det vil si 19. januar 2038 klokken 03:14:07 UTC. Ett sekund etter det, vipper telleren over til et negativt tall, og datologikken som er bygget på den verdien kan bryte sammen fullstendig. Moderne 64-bits systemer har ikke denne begrensningen i det hele tatt, siden 64 bit gir plass til tidsstempler langt, langt utover noe som er praktisk relevant.
Tidssoneforvirring. Et Unix-tidsstempel har i seg selv ingen tidssone, det er et absolutt øyeblikk i tid, akkurat som et bilde av en klokke som viser samme sekund uansett hvor på jorda du befinner deg. Forvirringen oppstår først når tallet skal vises for et menneske: en utvikler i Oslo og en i Tokyo som ser på nøyaktig samme tidsstempel, vil se to forskjellige klokkeslett dersom begge omregner til lokal tid, men det er fortsatt det samme øyeblikket.
Negative tidsstempler. Datoer før 1. januar 1970 representeres av negative tall. -86400 tilsvarer for eksempel 31. desember 1969, altså ett døgn (86400 sekunder) før epoken. Ikke alle verktøy og systemer støtter negative verdier, så sjekk dokumentasjonen før du forutsetter at et historisk årstall lar seg konvertere problemfritt.
Ofte stilte spørsmål
Hva er et Unix-tidsstempel? Det er antall sekunder som har gått siden 1. januar 1970 klokken 00:00:00 UTC, kjent som Unix-epoken. Det brukes universelt i databaser, API-er og programmeringsspråk for å representere et konkret tidspunkt uten tvetydighet rundt tidssoner.
Hvordan vet jeg om tidsstempelet mitt er i sekunder eller millisekunder? Tell sifrene. Et tidsstempel i sekunder har i dag 10 siffer (for eksempel 1700000000). Det samme øyeblikket i millisekunder har 13 siffer (1700000000000). Limer du en verdi med feil enhet inn i et system som forventer den andre, havner du enten svært langt inn i fremtiden eller svært nær 1970.
Hva er år 2038-problemet? Det er en overflyt-feil i systemer som lagrer tidsstempelet som et 32-bits signert heltall. Den høyeste verdien et slikt tall kan holde er 2147483647, som tilsvarer 19. januar 2038 klokken 03:14:07 UTC. Rett etter det tallet vipper telleren over til negativ, noe som kan ødelegge datologikk i eldre systemer. 64-bits systemer har ikke denne begrensningen.
Kan jeg konvertere en dato før 1970? Ja, en dato før 1. januar 1970 gir rett og slett et negativt tidsstempel. -86400 er for eksempel 31. desember 1969. Ikke alle systemer og verktøy godtar negative verdier, så det er verdt å teste eller sjekke dokumentasjonen dersom du jobber med historiske datoer.
Hvorfor lagrer databaser datoer som Unix-tidsstempler i stedet for en datotekst?
Fordi et heltall er raskere å sammenligne, sortere og regne med enn en tekststreng, og fordi det unngår all tvetydighet rundt format og tidssone. Å finne alle rader med en created_at nyere enn et gitt tidspunkt blir en enkel numerisk sammenligning i stedet for en tung tekstoperasjon, og verdien betyr det samme uansett hvilken server eller tidssone som leser den.