Artikel

Unix-tidsstempler og cron-udtryk forklaret

Et Unix-tidsstempel er blot et heltal. Et cron-udtryk er blot fem felter. Begge dukker konstant op i backend-arbejde, og begge slår folk ned på forudsigelige måder: det ene på grund af tidszoner, det andet på grund af enheden.

Skrevet af Bastien Sulyan · Udgivet den 28. juni 2026

Hvad et Unix-tidsstempel er

Et Unix-tidsstempel tæller antallet af sekunder der er gået siden 1970-01-01 00:00:00 UTC, et referencepunkt kendt som Unix epoch. Den definition har to vigtige konsekvenser. For det første er tællingen i UTC: der er ingen tidszone indlejret i selve tallet. 1718400000 betyder det samme øjeblik overalt på Jorden uanset hvor den maskine der gemmer det befinder sig. For det andet er epoch defineret i sekunder, ikke i nogen anden enhed. En værdi som 1718400000 er altid sekunder siden midnat 1. januar 1970 UTC, medmindre et system eller en protokol eksplicit har truffet et andet valg. Tidsstempler er tidszoneløse af design, hvilket er præcis grunden til at de er nyttige til logning, databaser og kommunikation mellem systemer hvor ure i forskellige regioner skal referere til det samme øjeblik utvetydigt.

Tidslinje der viser Unix epoch ved 1970-01-01 00:00:00 UTC til venstre, et nuværende tidsstempel i midten og 2038-overløbsgrænsen til højre, markeret med et fortegnet 32-bit heltals maksimum.

Sekunder, millisekunder og år-2038-problemet

Mange moderne runtimes og API'er bruger millisekunder frem for sekunder. JavaScripts Date.now() returnerer millisekunder, så 1718400000000 er det samme øjeblik som sekund-præcisionsværdien 1718400000. Når du modtager et ukendt tidsstempel, fortæller størrelsesordenen dig enheden: et 10-cifret tal er næsten altid sekunder; et 13-cifret tal er næsten altid millisekunder. År-2038-problemet opstår fra et andet valg: gemning af et sekund-præcisionsstempel i et fortegnet 32-bit heltal. Maksimumværdien af et fortegnet 32-bit heltal er 2147483647, som svarer til 2038-01-19 03:14:07 UTC. Efter dette sekund flyder tælleren over til et stort negativt tal og datoen ruller tilbage til 1901 på systemer der ikke håndterer grænsen. Løsningen er at bruge 64-bit lagring. De fleste nuværende operativsystemer og databaser gør allerede det, men indlejrede systemer, netværksenheder og gamle filformater der fastlåste feltbredden for årtier siden er stadig i fare.

Konvertering af epoch til en menneskelig dato: tidszonetrinet

Konvertering af en epoch-værdi til en læsbar dato kræver to trin: hent UTC-datokomponenterne fra heltallet, anvend derefter et UTC-offset for at få den lokale tid. Tidsstemplet i sig selv er UTC. Når du spørger, hvilken dato 1718325000 repræsenterer, er det korrekte svar den 2024-06-14 kl. 00:30 i UTC. I New York (UTC-4 om sommeren) falder det samme sekund den 2024-06-13 kl. 20:30 aftenen før: datoen ændrer sig, ikke kun timen. Det er det trin, der giver forkerte resultater, når det springes over: en udvikler logger det rå tidsstempel i UTC, et rapporteringsværktøj gengiver det i lokal tid uden konvertering, og datoen ser ud til at være forkert med timer eller en hel dag. Timestamp-converter-værktøjet på Sunasty håndterer dette eksplicit: du indtaster en epoch-værdi, og det viser UTC-datoen og -tiden ved siden af din enheds egen lokale dato og tid, så en dato-grænse-overskridelse som denne er synlig med det samme. Konverteringen kører udelukkende i browseren, og intet du indsætter, sendes nogen steder.

To kalendergitre side om side for samme epoch-værdi: UTC-gitteret fremhæver én kalenderdag, og gitteret for New York (UTC-4) fremhæver den foregående dag, hvilket viser, hvordan den lokale dato rykker tilbage på grund af tidsforskellen.

Cron-syntaks: fem felter, intervaller, trin og lister

Et cron-udtryk planlægger tilbagevendende jobs på Unix-lignende systemer. Standardsyntaksen har fem mellemrumsseparerede felter: minut (0-59), time (0-23), dag-i-måned (1-31), måned (1-12), dag-i-uge (0-7, hvor både 0 og 7 repræsenterer søndag). En stjerne (*) i et felt betyder "hver gyldig værdi". Udtrykket 30 8 * * 1-5 kører kl. 08:30 mandag til fredag. Intervaller bruger en bindestreg: 1-5 dækker værdierne 1, 2, 3, 4, 5. Lister bruger kommaer: 1,15 betyder den 1. og 15. Trin bruger en skråstreg: */15 i minutfeltet betyder hvert 15. minut (0, 15, 30, 45). Disse kombinatorer kan optræde sammen: 0-30/10 betyder 0, 10, 20, 30. Én ting cron ikke har er et tidszonefelt. Daemonen læser uret på den maskine den kører på, som er indstillet til serverens lokale tidszone. Hvis serveren kører UTC men en udvikler forventer lokal tid, afvikles tidsplanen på den forkerte urtime. Den praktiske regel er at behandle cron-tidsplaner som server-lokale-tidsudtryk og dokumentere serverens tidszone ved siden af cron-linjen.

Brug af timestamp-converter lokalt

Timestamp-converter på Sunasty konverterer i begge retninger: epoch til menneskelig dato og menneskelig dato tilbage til epoch. Du kan indtaste en sekund-præcisionsværdi eller en millisekund-præcisionsværdi; værktøjet registrerer enheden fra størrelsesordenen. Det viser resultatet i UTC og i din enheds egen lokale tidszone side om side, sammen med de rå sekund- og millisekundværdier klar til at kopiere. En Nu-knap udfylder det aktuelle tidsstempel med ét klik, hvilket er en hurtig måde at tjekke den aktuelle Unix-tid på uden at åbne en terminal. Der er ingen separat tidszonevælger: den lokale kolonne afspejler altid den tidszone, din browser aktuelt er indstillet til. Alt dette kører i browseren. Den værdi, du indsætter i feltet, læses af klient-side JavaScript og forlader aldrig enheden.

Værktøjer i denne artikel

Ofte stillede spørgsmål

Hvorfor bruger JavaScript millisekunder i stedet for sekunder?

JavaScripts Date-objekt var designet til at arbejde med sub-sekunds præcision fra starten, og millisekunder giver tusind gange opløsningen af sekunder uden at kræve et decimalpunkt. Afvejningen er at værdier er større, hvilket er grunden til at Date.now() producerer et 13-cifret tal mens de fleste server-side-tidsstempler er 10 cifre.

Skal enhver server der kører cron være på UTC?

Nej, men at køre servere på UTC er en almindelig praksis præcis fordi det fjerner tvetydigheden. Når en server er på UTC, betyder et cron-udtryk som 0 2 * * * kl. 02:00 UTC, og det tidspunkt er stabilt året rundt. På en server i en zone der overholder sommertid, afvikles det samme job ved et andet UTC-øjeblik om sommeren og vinteren, og det kan afvikles to gange eller springe over ved klokkeskiftet.

Hvad er den sikre lagringstype for tidsstempler efter 2038?

Et fortegnet 64-bit heltal indeholder sekund-præcisionsstempel op til år 292277026596, hvilket er langt ud over ethvert praktisk bekymring. De fleste nuværende databaser gemmer tidsstempler som 64-bit-værdier som standard. Hvis du arbejder med et ældre skema eller et binært filformat der bruger 32-bit-felter, er migration til 64-bit-lagring inden 2038-grænsen den korrekte løsning.