Unix Tidsstämpelomvandlare

Datum och Tid Omvandlare
Unix-tidsstämpel
Tidszon
Datum- och tidsformat
@ Format
DateTime
ISO 8601
RFC 3339
RFC 1123Z
RFC 822
RFC 822Z
RFC 1123
RFC 850
ANSIC
UnixDate
RubyDate
DateOnly
TimeOnly
Kitchen
Stamp
Lokalt format
Datumformat
Tidsformat
Hexadecimal
Relativ
Datum
- -
Tid
: :
UTC/GMT
Unix-tidsstämpel
Sekunder
Millisekunder
Mikrosekunder
Hexadecimal
Relativ

Introduktion

En Unix-tidsstämpel (eller epoktid) är standardsättet för datorer att representera tid: ett enda heltal som räknar sekunderna sedan 1 januari 1970 vid midnatt UTC, exklusive skottsekunder. Det förekommer i databasposter, API-svar, JWT-tokens, loggfiler, cron-scheman och cacheförfallohuvuden. Medan maskiner läser dessa heltal omedelbart, behöver människor dem översatta till kalenderdatum och klocktider — ofta i flera format samtidigt.

Unix-tidsstämpelomvandlaren är till för utvecklare, systemadministratörer och säkerhetsanalytiker som behöver avkoda tidsstämplar från loggar, verifiera tokenförfall, schemalägga cron-jobb över tidszoner, eller snabbt slå upp ett historiskt eller framtida epokvärde. Verktyget är uppdelat i två oberoende block:

  • Block A (Unix-tidsstämpel → Datum och tid): ange en numerisk tidsstämpel och se den renderad i 21 datum- och tidsformat, organiserade efter standardfamilj.
  • Block B (Datum och tid → Unix-tidsstämpel): välj ett kalenderdatum, tid och tidszonsförskjutning, och få motsvarande tidsstämpel i sekunder, millisekunder och mikrosekunder.

Båda blocken har sin egen tidszonsväljare, så du kan arbeta i UTC för en riktning och en anpassad förskjutning för den andra utan korskontaminering.

Så här fungerar det

Unixtid räknar sekunder från epoken (1 januari 1970, 00:00:00 UTC). Varje tick lägger till exakt en sekund. Eftersom den är förankrad till UTC representerar en Unix-tidsstämpel samma ögonblick överallt på jorden — tidszon spelar bara roll när du renderar den som en läsbar sträng.

Verktyget använder webbläsarens inbyggda JavaScript Date-objekt för alla konverteringar. Varje Date lagrar internt tid som ett enda tal: millisekunder sedan Unix-epoken. När du anger en tidsstämpel konstruerar verktyget en Date och läser dess UTC- eller lokala egenskaper beroende på den aktiva tidszonsväljaren. När du anger ett kalenderdatum och tid beräknar verktyget skillnaden från epoken justerad för den angivna tidszonsförskjutningen.

Tidsstämpelenheter över ekosystem

Olika plattformar och språk använder olika epokenheter. Verktygets enhetsväljare låter dig matcha din källas precision:

Enhet Används av Exempel
Sekunder Go, PHP, Python, PostgreSQL, Ruby, cron 10 siffror
Millisekunder JavaScript (Date.now()), Ethereum, .NET DateTimeOffset, Java System.currentTimeMillis() 13 siffror
Mikrosekunder Linux /proc/uptime, Go time.UnixMicro(), högupplöst profilering 16 siffror

Verktyget konverterar din indata till sekunder internt. Om du klistrar in ett 13-siffrigt värde från JavaScripts Date.now(), ställ in enheten på millisekunder så hanterar verktyget divisionen.

Tidszon och sommartid

En Unix-tidsstämpel representerar alltid samma fysiska ögonblick. Tidszonsväljaren i varje block ändrar bara hur det ögonblicket visas eller tolkas.

  • UTC-läge: renderar all utdata mot Coordinated Universal Time. RFC 3339-formatet använder en bokstavlig Z som suffix istället för +00:00.
  • Lokalt läge: använder din webbläsares systemtidszon, inklusive automatiska sommartidsjusteringar.
  • Anpassat läge: en numerisk UTC-förskjutning mellan -12:00 och +14:00. Verktyget tillämpar denna förskjutning direkt utan någon DST-korrigering — den behandlar din förskjutning som en fast väggklocka.

När sommartid är i kraft ändras den lokala tidszonsförskjutningen. Samma tidsstämpel som visas i lokalt läge kan visa en annan timme än den gjorde föregående månad. Detta är förväntat: tidsstämpeln är densamma, men den lokala klockkonventionen har ändrats.

För de lokalanpassade raderna (Locale, Locale Date, Locale Time) respekterar verktyget både den valda tidszonen och din webbläsares språkinställningar. Om du väljer UTC-läge får toLocaleString { timeZone: 'UTC' }, vilket säkerställer att lokalanpassningen använder korrekt tidszon.

Användning

Block A — Tidsstämpel till datum och tid

  1. Ange en Unix-tidsstämpel i inmatningsfältet (endast siffror, valfritt minustecken för före 1970).
  2. Välj inmatningsprecision: Sekunder, Millisekunder eller Mikrosekunder.
  3. Välj en tidszon: UTC, Lokal (din systemtidszon) eller Anpassad (ange en förskjutning mellan -12 och +14 i halvtimmessteg).
  4. Läs resultaten — 21 datum- och tidsformatrader uppdateras i realtid.

Block B — Datum och tid till tidsstämpel

  1. Ange året direkt. Använd rullgardinsmenyerna för månad, dag, timme, minut och sekund.
  2. Välj en tidszon från UTC/GMT-väljaren: Lokal matchar din systemtidszon; numeriska poster som UTC+8 behandlar indata som väggklocktid i den zonen.
  3. Tidsstämpelresultaten visas omedelbart i sekunder, millisekunder, mikrosekunder, hexadecimal och relativ tid.

De två blocken fungerar oberoende. Att ändra Block A påverkar inte Block B och vice versa. Detta låter dig jämföra tidsstämplar sida vid sida eller låsa ett referensvärde medan du utforskar olika format.

Handledning

Scenario 1: Avkoda en tidsstämpel från en serverlogg

Din applikationslogg visar tidsstämpeln 1742345678 — ett API-anrop som misslyckades. Du behöver veta exakt när det hände och även kontrollera HTTP-date-formatet för korrelation med HTTP-svarshuvuden.

  1. Öppna Unix-tidsstämpelomvandlaren.
  2. Skriv 1742345678 i Block A:s inmatningsfält.
  3. Resultaten visar 21 formatrader, inklusive:
    • @ Format: 3/19/2025 @ 2:14:38 PM +0000 (snabbavläsningsbart format)
    • RFC 1123Z: Wed, 19 Mar 2025 14:14:38 +0000 (HTTP-date-standard, matchar Date- och Last-Modified-huvuden)
    • Relativt: 124d (hur länge sedan förfrågan inträffade)
  4. Växla tidszonen till Lokal för att se vilken tid det var i din egen tidszon.

Scenario 2: Schemalägg ett cron-jobb vid en specifik tid

Du behöver ett cron-jobb som körs kl 03:30 Eastern Time den 15 juni 2026. Eastern Daylight Time är UTC-4 i juni.

  1. I Block B, ställ in datum till 15 juni 2026 och tid till 03:30:00.
  2. Ställ in UTC/GMT-väljaren till UTC+4 (EDT är UTC-4, ange alltså -4).
  3. Läs Sekunder-värdet — detta är din cron-tidsstämpel. Raderna Hex och Relativt uppdateras också, vilket ger dig en maskinläsbar och mänskligt läsbar referens samtidigt.

Proffstips

Användningsområden för format

Varje utdataformat tjänar ett specifikt syfte. Här är när du ska använda varje:

Format När du ska använda
@ Format Snabb visuell avläsning — den kompakta layouten M/D/YYYY @ HH:MM:SS AM/PM är läsbar i ett ögonkast
DateTime SQL-databasinlägg (YYYY-MM-DD HH:MM:SS), den vanligaste strängformen utanför JSON
ISO 8601 JSON-nyttolaster (new Date().toISOString()), REST API-begäran-/svarskroppar
RFC 3339 RSS-flöden, Atom-flöden, kalenderprenumerationer (iCalendar); används där ISO 8601 behöver en striktare profil
RFC 1123Z HTTP-huvuden (Date, Last-Modified, Expires), cookies (expires-attribut)
RFC 822 E-posthuvuden (Date-fältet), äldre diskussionsgruppsformat
RFC 850 Äldre HTTP/1.0-implementationer (ovanligt idag, behålls för bakåtkompatibilitet)
ANSIC Gos time.ANSIC-konstant — används vid läsning av Gos time.Time standardutdata
RubyDate Ruby's Time#ctime-format; matchar klassisk Unix ctime-utdata
DateOnly / TimeOnly Go 1.20+ bekvämlighetskonstanter — extrahera bara datumet eller bara tiden
Kitchen Gos 12-timmarsklockformat — snabb väggklocksavläsning
Locale Användargränssnittsvisning; respekterar webbläsarens språk- och kulturkonventioner
Hex Lågnivåfelsökning, firmware-tidsstämplar, inbyggda system
Relativt Dashboard-visningar, "tid sedan senaste händelse" UI-element

Språkimplementationer

Hämta aktuell Unix-tidsstämpel i ditt valda språk:

// Go
time.Now().Unix()      // sekunder
time.Now().UnixMilli() // millisekunder (Go 1.17+)
// JavaScript
Math.floor(Date.now() / 1000) // sekunder
Date.now()                     // millisekunder
// PHP
time();              // sekunder
intval(microtime(true) * 1000); // millisekunder
# Python
import time; int(time.time())         # sekunder
import time; int(time.time() * 1000)  # millisekunder

Allmänna tips

  • Tidsstämplar före 1970: Ange negativa värden. 1 december 1960 kl 00:00:00 UTC är -286329600.
  • Hex-indata: Hexadecimala värden (med eller utan 0x-prefix) tolkas automatiskt — ange 0x6618E1FE och se decimalmotsvarigheten.
  • Jämför tidszoner: Ställ in Block A:s tidszon till UTC och Block B:s tidszon till Lokal samtidigt för att se hur samma ögonblick renderas i båda.

Alternativ

Verktyg Tidsstämpel till datum Datum till tidsstämpel 21+ format Oberoende tidszon per block Klientsidan
Toollect Unix-tidsstämpelomvandlare Ja Ja Ja (21) Ja Ja
unixtimestamp.com Ja Ja ~5 Nej Ja
epochconverter.com Ja Ja ~8 Nej Ja
site24x7.com Ja Ja ~6 Full IANA Ja
date -d @timestamp (Linux) Ja Nej ~3 Endast system-TZ N/A

Felsökning

Problem Trolig orsak Lösning
Utdata visar ett datum 1970 eller 1969 Indata läses i fel enhet Ändra enhetsväljaren så den matchar din indata (sekunder / ms / μs)
Datum och tid visar fel ögonblick Tidszonsväljaren är felaktigt inställd Växla till UTC för att verifiera basögonblicket, justera sedan till korrekt förskjutning
Locale-raden visar fel tid Locale-formateringen ignorerar Block A:s tidszonsval Detta har åtgärdats — locale respekterar nu vald tidszon. Kontrollera att du använder senaste versionen
Utdata uppdateras inte Indata innehåller icke-numeriska tecken Rensa fältet och ange endast siffror och valfritt inledande minustecken
Relativ tid visar "just nu" för en känd tidigare tidsstämpel Relativ tid beräknas mot aktuell systemklocka Detta är förväntat — relativ tid jämför alltid tidsstämpeln med "nu"
13-siffrig indata visar ett datum långt i framtiden Indata är i millisekunder men enheten är som standard sekunder Växla enheten till "Millisekunder"

Tekniska specifikationer

  • Konverteringsmotor: JavaScript Date-objekt (ECMAScript-standard)
  • Tidsstämpelområde: Fullt JavaScript-nummeromfång (±9 kvadriljoner sekunder, täcker miljarder år)
  • Indatastöd: Decimala heltal, negativa värden (före 1970)
  • Indataprecision: Sekunder, millisekunder eller mikrosekunder (konfigurerbar)
  • Tidszonsstöd: UTC, lokal (webbläsarsystem), anpassad GMT-förskjutning (-12 till +14 i 0,5-timmarssteg); oberoende för varje block

De 21 formatfamiljerna

# Grupp Format Exempel
1 Vanlig @ Format 3/19/2025 @ 2:14:38 PM +0000
2 Vanlig DateTime 2025-03-19 14:14:38
3 Vanlig ISO 8601 2025-03-19T14:14:38+00:00
4 Vanlig RFC 3339 2025-03-19T14:14:38Z (UTC använder Z)
5 RFC RFC 1123Z Wed, 19 Mar 2025 14:14:38 +0000
6 RFC RFC 822 19 Mar 25 14:14 UTC
7 RFC RFC 822Z 19 Mar 25 14:14 +0000
8 RFC RFC 1123 Wed, 19 Mar 2025 14:14:38 UTC
9 RFC RFC 850 Wednesday, 19-Mar-25 14:14:38 UTC
10 Go ANSIC Wed Mar 19 14:14:38 2025
11 Go UnixDate Wed Mar 19 14:14:38 UTC 2025
12 Go RubyDate Wed Mar 19 14:14:38 +0000 2025
13 Go DateOnly 2025-03-19
14 Go TimeOnly 14:14:38
15 Go Kitchen 2:14PM
16 Go Stamp Mar 19 14:14:38
17 Locale Locale 3/19/2025, 2:14:38 PM (webbläsarberoende)
18 Locale Locale Date 3/19/2025
19 Locale Locale Time 2:14:38 PM
20 Annat Hex 0x6618E1FE
21 Annat Relativt 124d

Formatfamiljeträd

Datum- och tidsformaten i detta verktyg härstammar från fyra linjer:

  • RFC 822 (1982) definierade det ursprungliga e-postdatumformatet med 2-siffrigt år. RFC 1123 (1989) ersatte det med 4-siffrigt år. RFC 1123Z är samma format som använder en numerisk tidszonsförskjutning (+0000) istället för en alfabetisk förkortning (UTC). Tillsammans täcker dessa HTTP-huvuden (1123Z) och e-postformat (822).
  • ISO 8601 (1988) etablerade den internationella standarden för datum- och tidsrepresentation. RFC 3339 (2002) profilerar ISO 8601 för internetanvändning och lägger till krav som obligatoriskt Z för UTC. De flesta moderna API:er väljer en av dessa två.
  • Go-tidskonstanter (ANSIC, UnixDate, RubyDate, etc.) är bekvämlighetslayouter inbyggda i Gos standardbibliotek. De speglar POSIX-konventioner (ctime-utdata), RFC-standarder och Go-specifika bekvämlighetsformer (DateOnly, Kitchen, Stamp).
  • Locale-format använder webbläsarens Intl.DateTimeFormat-API, som följer Unicode Common Locale Data Repository (CLDR). Den exakta utdatan beror på användarens webbläsarspråkinställning.

Kompatibilitet

  • Webbläsare: Chrome 90+, Firefox 90+, Safari 15+, Edge 90+
  • Beroenden: Inga — ren JavaScript, inga tredjepartsbibliotek
  • Databehandling: 100% klientsida — inga nätverksförfrågningar

Funktioner

  • Tvävägskonvertering mellan Unix-tidsstämplar och läsbara datum
  • Realtidsvisning av aktuell Unix-tidsstämpel med automatiska uppdateringar
  • Flera utdataformat: UTC, lokal tid, ISO 8601, hex och relativ tid
  • Anpassat stöd för tidszonsförskjutning för korrekt datum-till-tidsstämpelkonvertering
  • Klientbearbetning — ingen data skickas till någon server

Vanliga frågor

Vad är en Unix-tidsstämpel?
En Unix-tidsstämpel (även kallad epoktid) är antalet sekunder som förflutit sedan 1 januari 1970 kl 00:00:00 UTC. Det är ett universellt sätt för datorer att representera tid som ett enda heltal, oberoende av tidszoner och kalenderformat.
Hur vet jag om min tidsstämpel är i sekunder eller millisekunder?
En Unix-tidsstämpel i sekunder har 10 siffror (t.ex. 1712345678), medan en millisekund-tidsstämpel har 13 siffror (t.ex. 1712345678000). Vårt verktyg behandlar all indata som sekunder. Utmatningstabellen visar även motsvarigheten i millisekunder som referens.
Hanterar detta verktyg datum före 1970?
Ja. Datum före 1 januari 1970 representeras som negativa Unix-tidsstämplar. Till exempel är 31 december 1969 kl 23:59:00 UTC -60 sekunder. Ange ett negativt värde så konverterar verktyget det korrekt.
Skickas min data till en server?
Nej. All konvertering sker helt i din webbläsare. Ingen data överförs över nätverket, vilket gör detta verktyg säkert för bearbetning av tidsstämplar från privata loggar eller konfidentiella system.
Vad är år-2038-problemet?
Den 19 januari 2038 kl 03:14:07 UTC kommer 32-bitars signerade heltals Unix-tidsstämplar att flöda över — maxvärdet 2 147 483 647 blir -2 147 483 648, vilket representerar 13 december 1901. De flesta moderna system använder 64-bitars heltal, vilket undviker detta problem i miljarder år.
Vad är skillnaden mellan ISO 8601 och RFC 3339?
RFC 3339 är en profil av ISO 8601. De delar samma grundformat (YYYY-MM-DDTHH:MM:SS±HH:MM), men RFC 3339 kräver tidszonsbeteckning (Z för UTC, eller ±HH:MM) och kräver ett tresiffrigt årsintervall. I praktiken accepterar de flesta moderna API:er båda formaten omväxlande.
ESC