Artikkel

Unix-tidsstempler og cron-uttrykk forklart

Et Unix-tidsstempel er bare et heltall. Et cron-uttrykk er bare fem felt. Begge dukker stadig opp i backend-arbeid, og begge snubler folk over på forutsigbare måter: det ene på grunn av tidssoner, det andre på grunn av enheten.

Skrevet av Bastien Sulyan · Publisert 28. juni 2026

Hva et Unix-tidsstempel er

Et Unix-tidsstempel teller antall sekunder som har gått siden 1970-01-01 00:00:00 UTC, et referansepunkt kjent som Unix-epoken. Den definisjonen har to viktige konsekvenser. For det første er tellingen i UTC: det er ingen tidssone innebygd i selve tallet. 1718400000 betyr det samme øyeblikket overalt på jorden uavhengig av hvor maskinen som lagrer det befinner seg. For det andre er epoken definert i sekunder, ikke i noen annen enhet. En verdi som 1718400000 er alltid sekunder siden midnatt 1. januar 1970 UTC, med mindre et system eller protokoll eksplisitt har gjort et annet valg. Tidsstempler er uten tidssone per design, noe som er nøyaktig grunnen til at de er nyttige for logging, databaser og kommunikasjon mellom systemer der klokker i forskjellige regioner må referere til det samme øyeblikket entydig.

Tidslinje som viser Unix-epoken ved 1970-01-01 00:00:00 UTC til venstre, et gjeldende tidsstempel i midten og 2038-overflytgrensen til høyre, merket med maksimumsverdien til et fortegnet 32-bit heltall.

Sekunder, millisekunder og år-2038-problemet

Mange moderne kjøremiljøer og API-er bruker millisekunder i stedet for sekunder. JavaScripts Date.now() returnerer millisekunder, så 1718400000000 er det samme øyeblikket som sekund-presisjonsverdien 1718400000. Når du mottar et ukjent tidsstempel, forteller størrelsesorden deg enheten: et 10-sifret tall er nesten alltid sekunder; et 13-sifret tall er nesten alltid millisekunder. År-2038-problemet oppstår fra et annet valg: å lagre et sekund-presisjons-tidsstempel i et fortegnet 32-bit heltall. Maksimumsverdien til et fortegnet 32-bit heltall er 2147483647, som tilsvarer 2038-01-19 03:14:07 UTC. Etter det sekundet renner telleren over til et stort negativt tall, og datoen går tilbake til 1901 på systemer som ikke håndterer grensen. Løsningen er å bruke 64-bit lagring. De fleste moderne operativsystemer og databaser gjør allerede det, men innebygde systemer, nettverksenheter og gamle filformater som fastsatte feltbredden for tiår siden, er fortsatt i faresonen.

Konvertere epoke til en lesbar dato: tidssone-trinnet

Å konvertere en epokeverdi til en lesbar dato krever to trinn: hente UTC-datokomponentene fra heltallet, deretter bruke et UTC-offset for å få lokal tid. Tidsstempelet i seg selv er UTC. Når du spør om hvilken dato 1718325000 representerer, er det riktige svaret 2024-06-14 klokken 00:30 i UTC. I New York (UTC-4 om sommeren) faller det samme sekundet på kvelden før, 2024-06-13 klokken 20:30: datoen endres, ikke bare timen. Dette er trinnet som gir feil resultater når det hoppes over: en utvikler logger rå tidsstempelet i UTC, et rapporteringsverktøy viser det i lokal tid uten konvertering, og datoen ser ut til å være feil med timer eller en hel dag. Tidsstempelkonverteringsverktøyet på Sunasty håndterer dette eksplisitt: du oppgir en epokeverdi, og verktøyet viser UTC-datoen og klokkeslettet ved siden av enhetens egen lokale dato og klokkeslett, slik at en dagsgrense-overgang som denne er synlig med ett blikk. Konverteringen kjører utelukkende i nettleseren og ingenting du limer inn sendes noe sted.

To kalenderrutenett side om side for samme epokeverdi: UTC-rutenettet fremhever én kalenderdag, og rutenettet for New York (UTC-4) fremhever forrige dag, noe som viser hvordan den lokale datoen flyttes tilbake på grunn av tidsforskjellen.

Cron-syntaks: fem felt, intervaller, steg og lister

Et cron-uttrykk planlegger tilbakevendende jobber på Unix-lignende systemer. Standardsyntaksen har fem mellomromsseparerte felt: minutt (0-59), time (0-23), dag-i-måneden (1-31), måned (1-12), dag-i-uken (0-7, der både 0 og 7 representerer søndag). En stjerne (*) i et felt betyr «alle gyldige verdier». Uttrykket 30 8 * * 1-5 kjøres klokken 08:30 mandag til fredag. Intervaller bruker en bindestrek: 1-5 dekker verdiene 1, 2, 3, 4, 5. Lister bruker kommaer: 1,15 betyr den 1. og 15. Steg bruker en skråstrek: */15 i minutt-feltet betyr hvert 15. minutt (0, 15, 30, 45). Disse kombinatorene kan vises sammen: 0-30/10 betyr 0, 10, 20, 30. Én ting cron ikke har er et tidssone-felt. Daemonen leser klokken til maskinen den kjører på, som er satt til serverens lokale tidssone. Hvis serveren kjører UTC, men en utvikler forventer lokal tid, kjøres jobben på feil klokketime. Den praktiske regelen er å behandle cron-planer som server-lokal-tid-uttrykk og dokumentere serverens tidssone ved siden av cron-linjen.

Bruke tidsstempel-konverteren lokalt

Tidsstempel-konverteren på Sunasty konverterer begge veier: epoke til menneskelesbar dato og menneskelesbar dato tilbake til epoke. Du kan oppgi en sekund-presisjonsverdi eller en millisekund-presisjonsverdi; verktøyet oppdager enheten fra størrelsesorden. Det viser resultatet i UTC og i enhetens egen lokale tidssone side om side, sammen med rå sekund- og millisekundverdier klare til å kopiere. En Nå-knapp fyller inn gjeldende tidsstempel med ett klikk, noe som er en rask måte å sjekke gjeldende Unix-tid uten å åpne en terminal. Det finnes ingen egen tidssonevelger: den lokale kolonnen gjenspeiler alltid tidssonen nettleseren din er stilt inn på. Alt dette kjøres i nettleseren. Verdien du limer inn i feltet leses av klient-side JavaScript og forlater aldri enheten.

Verktøy i denne artikkelen

Ofte stilte spørsmål

Hvorfor bruker JavaScript millisekunder i stedet for sekunder?

JavaScripts Date-objekt ble designet for å fungere med sub-sekunds presisjon fra starten, og millisekunder gir tusen ganger oppløsningen til sekunder uten å kreve et desimalkomma. Avveiningen er at verdiene er større, noe som er grunnen til at Date.now() produserer et 13-sifret tall mens de fleste server-side tidsstempler er 10 sifre.

Trenger alle servere som kjører cron å være på UTC?

Nei, men å kjøre servere på UTC er vanlig praksis nettopp fordi det fjerner tvetydigheten. Når en server er på UTC, betyr et cron-uttrykk som 0 2 * * * 02:00 UTC, og den tiden er stabil hele året. På en server i en sone som observerer sommertid, kjøres den samme jobben på et annet UTC-øyeblikk om sommeren og om vinteren, og den kan kjøres to ganger eller hoppe over én gang ved klokkeskiftet.

Hva er den sikre lagringstypen for tidsstempler etter 2038?

Et fortegnet 64-bit heltall holder sekund-presisjonsstempler opp til år 292277026596, noe som er langt utover enhver praktisk bekymring. De fleste nåværende databaser lagrer tidsstempler som 64-bit verdier som standard. Hvis du arbeider med et eldre skjema eller et binært filformat som bruker 32-bit felt, er migrering til 64-bit lagring før 2038-grensen den riktige løsningen.