Unix-tidsstämplar utan huvudvärk
Fråga tre utvecklare vad klockan är och du kan få tre olika svar, beroende på var de sitter. Fråga en Unix-tidsstämpel och du får exakt ett tal, samma för alla på planeten. Det enda heltalet är varför epoktid tyst underbygger nästan varje loggfil, databasrad och API-svar du någonsin kommer i kontakt med. Den här sidan förklarar vad det talet betyder, hur man läser det i båda riktningarna, och var det brukar bita folk i baken.
Vad Unix-tid egentligen är
En Unix-tidsstämpel är antalet sekunder som förflutit sedan 00:00:00 UTC den 1 januari 1970, utan att räkna skottsekunder. Den tidpunkten kallas epoken, och den valdes av tidiga Unix-ingenjörer helt enkelt för att det var ett bekvämt runt datum att räkna från. Vid epoken är värdet exakt 0. Varje sekund sedan dess lägger till ett, så talet bara växer. Datum före 1970 är fullt giltiga också, uttryckta som negativa heltal.
Du kommer också se det här begreppet kallat POSIX-tid eller, löst, epoktid. Oavsett etikett är mekaniken densamma: en ständigt växande räknare av sekunder. Eftersom det är ett vanligt heltal snarare än en formaterad sträng kan en dator lagra det på några bytes och jämföra två av dem med en enda subtraktion.
Sekunder, millisekunder och släktingar
Klassisk Unix-tid räknar hela sekunder, vilket ger det bekanta tiosiffriga talet du ser idag. Men många miljöer behöver finare upplösning. JavaScript, till exempel, arbetar i millisekunder och producerar ett trettonsiffrigt värde, och vissa system går ännu längre in i mikrosekunder eller nanosekunder. En pålitlig tumregel: ett tiosiffrigt tal är sekunder, tretton siffror är millisekunder. Om ditt konverterade datum hamnar någonstans runt 1970 när du förväntade dig dagens datum har du nästan säkert matat millisekunder in i ett sekundfält, eller tvärtom. Vår konverterare känner automatiskt av storleksordningen så du sällan behöver gissa.
Varför utvecklare litar på det
Den stora vinsten är att en tidsstämpel är tidszonsneutral. Heltalet 1735689600 refererar till samma ögonblick i Tokyo, Berlin och São Paulo. Att lagra det talet istället för en formaterad lokal sträng betyder att du aldrig behöver undra vilken klocka ett värde tillhörde. Sortering är också trivialt, eftersom kronologisk ordning bara är numerisk ordning, så ett databasindex över en tidsstämpelkolumn sorterar händelser korrekt utan någon parsning. Aritmetik är lika ren: gapet mellan två händelser är en subtraktion, och att lägga till en dag är att lägga till 86400. Dessa egenskaper är precis varför loggar, tokens, cachar och meddelandeköer alla förlitar sig på epoktid.
Konvertering i båda riktningarna
Att gå från en tidsstämpel till ett mänskligt datum innebär att ta antalet sekunder och projicera det på en kalender, och sedan formatera det i den tidszon du bryr dig om. Åt andra hållet tar du ett år, en månad, en dag och en tid, bestämmer vilken tidszon det uttrycks i, och kollapsar det tillbaka till sekunder sedan epoken. Vårt verktyg gör båda riktningarna direkt och helt i din webbläsare, så ingenting du klistrar in lämnar din dator. Klistra in ett tal för att avkoda det, eller välj ett datum för att koda det, och läs resultatet i både UTC och din lokala tid i samma ögonblick.
UTC kontra lokal tid, den klassiska fällan
Tidsstämpeln i sig har ingen tidszon; den är alltid förankrad till UTC. Förvirringen uppstår bara när du visar den. Om du konverterar 1700000000 och din skärm visar en kvällstimme medan en kollega i ett annat land ser en eftermiddagstimme är ingenting trasigt, ni tittar båda på samma ögonblick återgivet i olika lokala klockor. Buggar smyger sig in när kod läser ett lokalt datum som om det vore UTC, eller stämplar en väggklockstid utan att registrera offseten. Den säkra vanan är att lagra och överföra UTC, och bara applicera en lokal offset i sista ögonblicket, när du visar värdet för en människa. Vid tvekan, jämför mot UTC-raden i konverteraren snarare än din lokala.
Problemet år 2038
Många äldre system lagrade Unix-tid i ett signerat 32-bitars heltal. Det fältet får slut på plats en sekund efter 03:14:07 UTC den 19 januari 2038, då räknaren svämmar över och slår om till ett negativt tal, potentiellt kastande datum tillbaka till 1901. Det är samma typ av problem som Y2K. Den goda nyheten är att moderna operativsystem och språk till stor del har flyttat till 64-bitars tidsstämplar, som inte kommer svämma över på ungefär 292 miljarder år, så för ny kod är det mest en historisk kuriositet värd att känna till snarare än en nödsituation.
För fler webbläsarbaserade hjälpmedel, se våra utvecklarverktyg, och om du behöver räkna på siffrorna själv finns kalkylatorerna ett klick bort.
Vanliga frågor
Vad är en Unix-tidsstämpel?
Det är antalet sekunder sedan 00:00:00 UTC den 1 januari 1970, utan att räkna skottsekunder. Den startpunkten kallas epoken, och räkningen bara ökar över tid.
Varför konverteras mitt tal till ett datum nära 1970?
Du har troligen blandat ihop sekunder och millisekunder. Ett tiosiffrigt tal är sekunder och ett trettonsiffrigt tal är millisekunder. Att mata millisekunder in i ett sekundfält delar den skenbara tiden med ungefär tusen, vilket landar dig nära epoken.
Har en Unix-tidsstämpel en tidszon?
Nej. Värdet är alltid förankrat till UTC. En tidszon kommer bara in i bilden när du visar tidsstämpeln som ett läsbart datum, vilket är varför samma tal kan visa olika väggklockstider för olika personer.
Hur konverterar jag ett datum tillbaka till en tidsstämpel?
Ange år, månad, dag och tid, bestäm vilken tidszon det datumet uttrycks i, och verktyget kollapsar det till sekunder sedan epoken. Du kan göra båda riktningarna på den här sidan direkt i din webbläsare.
Vad är problemet år 2038?
System som lagrar Unix-tid i ett signerat 32-bitars heltal svämmar över en sekund efter 03:14:07 UTC den 19 januari 2038. Moderna 64-bitars tidsstämplar undviker detta i miljarder år, så det mesta av dagens mjukvara påverkas inte.
Skickas min data till en server?
Nej. Konverteringen körs helt i din webbläsare, så all tidsstämpel eller datum du klistrar in stannar på din egen enhet.