Artikel

Unix-tidsstämplar och cron-uttryck förklarade

En Unix-tidsstämpel är bara ett heltal. Ett cron-uttryck är bara fem fält. Båda dyker upp ständigt i backend-arbete, och båda orsakar problem på förutsägbara sätt: det ena på grund av tidszoner, det andra på grund av enheten.

Skrivet av Bastien Sulyan · Publicerat den 28 juni 2026

Vad en Unix-tidsstämpel är

En Unix-tidsstämpel räknar antalet sekunder som har förflutit sedan 1970-01-01 00:00:00 UTC, en referenspunkt känd som Unix epoch. Den definitionen har två viktiga konsekvenser. Först är räkningen i UTC: det finns ingen tidszon inbäddad i själva talet. 1718400000 betyder samma ögonblick överallt på jorden oavsett var maskinen som lagrar det befinner sig. Sedan är epoch definierad i sekunder, inte i någon annan enhet. Ett värde som 1718400000 är alltid sekunder sedan midnatt 1 januari 1970 UTC, om inte ett system eller protokoll uttryckligen har gjort ett annat val. Tidsstämplar är tidszonfria per design, vilket är exakt varför de är användbara för loggning, databaser och kommunikation mellan system där klockor i olika regioner måste hänvisa till samma ögonblick utan tvetydighet.

Tidslinje som visar Unix epoch vid 1970-01-01 00:00:00 UTC till vänster, en aktuell tidsstämpel i mitten och 2038-spill-gränsen till höger, markerad med ett signerat 32-bitarsheltals maximum.

Sekunder, millisekunder och 2038-problemet

Många moderna runtime-miljöer och API:er använder millisekunder snarare än sekunder. JavaScripts Date.now() returnerar millisekunder, så 1718400000000 är samma ögonblick som sekund-precisionsvärdet 1718400000. När du tar emot en okänd tidsstämpel berättar storleksordningen dig enheten: ett 10-siffrigt tal är nästan alltid sekunder; ett 13-siffrigt tal är nästan alltid millisekunder. 2038-problemet uppstår från ett annat val: att lagra en sekund-precisions-tidsstämpel i ett signerat 32-bitarsheltallet. Det maximala värdet av ett signerat 32-bitarshelttal är 2147483647, vilket motsvarar 2038-01-19 03:14:07 UTC. Efter den sekunden svämmar räknaren över till ett stort negativt tal och datumet rullar tillbaka till 1901 på system som inte hanterar gränsen. Lösningen är att använda 64-bitarslagring. De flesta aktuella operativsystem och databaser gör redan det, men inbyggda system, nätverksenheter och gamla filformat som fastnade fältbredden för decennier sedan är fortfarande i riskzonen.

Omvandla epoch till ett läsbart datum: tidszonessteget

Att omvandla ett epoch-värde till ett läsbart datum kräver två steg: hämta UTC-datumkomponenterna från heltalet och tillämpa sedan en UTC-förskjutning för att få lokal tid. Tidsstämpeln i sig är UTC. När du frågar vilket datum 1718325000 representerar är det korrekta svaret 2024-06-14 kl. 00:30 i UTC. I New York (UTC-4 på sommaren) infaller samma sekund den 2024-06-13 kl. 20:30 kvällen innan: datumet ändras, inte bara timmen. Det är det steg som producerar fel resultat när det hoppas över: en utvecklare loggar den råa tidsstämpeln i UTC, ett rapporteringsverktyg renderar det i lokal tid utan konvertering, och datumet verkar vara fel med timmar eller en hel dag. Verktyget timestamp-converter på Sunasty hanterar detta explicit: du anger ett epoch-värde och det visar UTC-datumet och tiden bredvid din enhets egen lokala datum och tid, så att en dagsgränsövergång som denna syns direkt. Konverteringen körs helt i webbläsaren och ingenting du klistrar in skickas någonstans.

Två kalenderrutnät sida vid sida för samma epoch-värde: UTC-rutnätet markerar en kalenderdag och rutnätet för New York (UTC-4) markerar föregående dag, vilket visar hur det lokala datumet flyttas bakåt på grund av tidsskillnaden.

Cron-syntax: fem fält, intervaller, steg och listor

Ett cron-uttryck schemalägger återkommande jobb på Unix-liknande system. Standardsyntaxen har fem blankstegsavgränsade fält: minut (0-59), timme (0-23), dag i månaden (1-31), månad (1-12), veckodag (0-7, där både 0 och 7 representerar söndag). En stjärna (*) i ett fält betyder "varje giltigt värde". Uttrycket 30 8 * * 1-5 körs kl. 08:30 måndag till fredag. Intervaller använder ett bindestreck: 1-5 täcker värdena 1, 2, 3, 4, 5. Listor använder kommatecken: 1,15 betyder den 1:a och 15:e. Steg använder ett snedstreck: */15 i minutfältet betyder var 15:e minut (0, 15, 30, 45). Dessa kombinatorer kan visas tillsammans: 0-30/10 betyder 0, 10, 20, 30. En sak cron inte har är ett tidszonsfält. Daemon läser klockan på den maskin den kör på, som är inställd på serverns lokala tidszon. Om servern kör UTC men en utvecklare förväntar sig lokal tid avfyras schemat vid fel klocktimme. Den praktiska regeln är att behandla cron-scheman som server-lokal-tid-uttryck och dokumentera serverns tidszon bredvid cron-raden.

Använda timestamp-converter lokalt

Verktyget timestamp-converter på Sunasty omvandlar i båda riktningarna: epoch till läsbart datum och läsbart datum tillbaka till epoch. Du kan ange ett sekund-precisionsvärde eller ett millisekund-precisionsvärde; verktyget identifierar enheten från storleksordningen. Det visar resultatet i UTC och i din enhets egen lokala tidszon sida vid sida, tillsammans med de råa värdena i sekunder och millisekunder redo att kopiera. En Nu-knapp fyller i den aktuella tidsstämpeln med ett klick, vilket är ett snabbt sätt att kontrollera den aktuella Unix-tiden utan att öppna en terminal. Det finns ingen separat tidszonväljare: den lokala kolumnen återspeglar alltid vilken tidszon din webbläsare för närvarande är inställd på. Allt detta körs i webbläsaren. Värdet du klistrar in i fältet läses av klientsidans JavaScript och lämnar aldrig enheten.

Verktyg i den här artikeln

Vanliga frågor

Varför använder JavaScript millisekunder istället för sekunder?

JavaScripts Date-objekt designades för att arbeta med sub-sekund precision från start, och millisekunder ger tusen gånger upplösningen av sekunder utan att kräva ett decimalkomma. Avvägningen är att värden är större, vilket är varför Date.now() producerar ett 13-siffrigt tal medan de flesta server-side-tidsstämplar är 10 siffror.

Måste varje server som kör cron vara på UTC?

Nej, men att köra servrar på UTC är en vanlig praxis exakt för att det tar bort tvetydigheten. När en server är på UTC innebär ett cron-uttryck som 0 2 * * * 02:00 UTC och den tiden är stabil året runt. På en server i en zon som observerar sommartid avfyras samma jobb vid ett annat UTC-ögonblick på sommaren och vintern, och det kan avfyras två gånger eller hoppas över vid klockbytet.

Vad är den säkra lagringstypen för tidsstämplar efter 2038?

Ett signerat 64-bitarshelttal håller sekund-precisions-tidsstämplar upp till år 292277026596, vilket är långt utanför alla praktiska farhågor. De flesta aktuella databaser lagrar tidsstämplar som 64-bitarsvärden som standard. Om du arbetar med ett äldre schema eller ett binärt filformat som använder 32-bitarsfält är migrering till 64-bitarslagring före 2038-gränsen den korrekta åtgärden.