Tidsstämpelkonverterare
Konvertera mellan Unix-tidsstämplar och läsbara datum
Funktioner
- Tvåvägskonvertering mellan Unix-tidsstämplar (sekunder sedan 1970-01-01T00:00:00Z) och läsbara datum via webbläsarens inbyggda Date-objekt
- Liveindikator för aktuell epoch med uppdatering på ett klick, plus formaterad utdata i webbläsarens lokal och i ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ)
- Snabbgenvägar för relativ tid: 1 timme sedan, 1 dag sedan, 1 vecka sedan, 1 månad sedan — beräknas i klickögonblicket
- Inbyggda referenstidsstämplar: Unix-epoch (1 jan. 1970), Y2K (1 jan. 2000), iPhone-lansering (29 juni 2007), Bitcoin Genesis Block (3 jan. 2009)
- Accepterar standardformat som Date.parse hanterar: ISO 8601, RFC 2822, datetime-local och många lokalsträngar
- Indatavalidering som skiljer ogiltig-tidsstämpel (icke-numerisk indata) från ogiltigt-datum (ej tolkningsbart) med tydliga lokaliserade meddelanden
- Knappen 'Aktuell tid' fyller datumfältet med nuvarande lokala tid i datetime-local-format och konverterar omedelbart
- Kopieringsknappar bredvid varje resultat — tomma fält och felstatus utesluts så att urklipp aldrig får inaktuellt innehåll
Så använder du
- För att göra om en tidsstämpel till datum, klistra in en 10-siffrig Unix-epoch (sekunder) i Tidsstämpel-fältet; verktyget multiplicerar med 1000 för Date().
- För att göra om ett datum till tidsstämpel, skriv eller klistra in ett datum i ett format som Date() kan tolka (ISO 8601 som 2026-01-15T10:30:00Z fungerar bäst).
- Eller klicka på 'Aktuell tid' för att fylla datumfältet med just nu och se motsvarande epoch.
- Använd snabbkonverteringarna (1 timme/dag/vecka/månad sedan) för relativa tidsstämplar vid loggfiltrering eller cache-TTL-räkning.
- Klicka på kopieringsikonen bredvid ett resultat; utdata visas i webbläsarens lokal samt ISO 8601 för maskinanvändning.
- Tryck Rensa för att nollställa båda fälten när du startar en ny konvertering.
Tips och bästa praxis
- Ange alltid tidszon när du arbetar med tidsstämplar för att undvika förvirring.
- Använd UTC som referenstidszon för internationella applikationer.
- Dubbelkolla sommartidsövergångar vid konvertering av datum.
- Bokmärk ofta använda konverteringar för snabbare åtkomst.
- Kopiera resultat direkt till din kod eller dina konfigurationsfiler.
Vanliga frågor
Sekunder eller millisekunder — vilken Unix-tidsstämpel förväntar sig verktyget?
Verktyget använder Unix-tidsstämplar i sekunder (10 siffror för aktuella datum, t.ex. 1735689600) — POSIX-standarden som C time(), Linux, MySQL UNIX_TIMESTAMP() och de flesta API:er använder. JavaScripts Date.now() och många JSON-API:er använder millisekunder (13 siffror). Har du ett 13-siffrigt tal, dela med 1000 innan du klistrar in, eller klistra datumsträngen direkt i Datum-fältet.
Hur hanteras tidszoner?
Unix-tidsstämplar är till sin natur UTC — samma ögonblick oavsett tidszon. Vid konvertering tidsstämpel→datum använder utdata din lokala webbläsartidszon via toLocaleString(), medan ISO-fältet visar UTC-motsvarigheten. Vid konvertering datum→tidsstämpel tolkas tvetydiga strängar (t.ex. '2026-01-15') som din lokala tidszon, medan ISO-strängar som slutar med Z eller en offset (+02:00) är otvetydiga. Ange alltid offset för pålitlighet mellan system.
Vad är Unix-epoch och varför 1 januari 1970?
Unix-epoch är 1970-01-01T00:00:00Z, vald av Bell Labs som en jämn referenspunkt nära Unix-utvecklingen (1969-1971). Tidsstämpel 0 motsvarar exakt det ögonblicket; tidsstämplar räknar sekunderna sedan dess (negativa värden är före 1970). Nästan alla moderna operativsystem och programmeringsspråk räknar från samma epoch, vilket gör den till tidens lingua franca inom datavetenskapen.
Hur är det med år 2038-problemet?
System som lagrar Unix-tidsstämplar som signerade 32-bitarsheltal får overflow den 19 januari 2038 kl. 03:14:07 UTC (tidsstämpel 2147483647) och slår över till ett negativt värde som representerar 1901. JavaScript och moderna 64-bitarssystem använder 64-bitarstal och är säkra i ~292 miljarder år. Granskar du gammal C-kod, MySQL TIMESTAMP-kolumner eller inbyggd firmware, planera migrering till 64-bitars time_t eller Unix-millisekunder före 2038.
Kan jag konvertera en tidsstämpel specifikt till ISO 8601?
Ja — efter konvertering visar verktyget även ISO 8601-formen via Date.toISOString(), nämligen YYYY-MM-DDTHH:mm:ss.sssZ i UTC. ISO 8601 är det enda formatet du bör skicka mellan system: entydigt, sorterbart som sträng och inbyggt stöd i JavaScript, Pythons fromisoformat, Postgres TIMESTAMPTZ och i princip varje modernt API. Undvik amerikanskt 'MM/DD/YYYY' eller europeiskt 'DD/MM/YYYY' för data mellan system.
Varför returnerar min datumsträng ett ogiltigt-datum-fel?
Date.parse är tolerant men inkonsekvent mellan webbläsare för icke-ISO-format. Tillförlitliga indata är ISO 8601 ('2026-01-15T10:30:00Z'), datetime-local-formatet ('2026-01-15T10:30') och fullt RFC 2822 ('Thu, 15 Jan 2026 10:30:00 GMT'). Undvik nakna format som '15/01/2026' (tvetydigt) eller 'Jan 15' (saknar år). Har du ett eget format från en loggfil, normalisera det först till ISO 8601.
Fungerar det för SQL-tidsstämplar och databasfält?
Ja, med en reservation: de flesta SQL-servrar lagrar TIMESTAMP/DATETIME utan tidszonsinformation, så det du ser i en kolumn är väggklockstid relativt serverns sessionstidszon. Lägg till serverns offset före inklistring (t.ex. '2026-01-15 10:30:00+00'). PostgreSQL TIMESTAMPTZ, MySQL TIMESTAMP (lagras internt som UTC) och SQLite fungerar alla bra med ISO 8601.
Skickas något till en server?
Nej. Alla konverteringar använder webbläsarens inbyggda Date-konstruktor och Math.floor — ingen nätverksanrop. Klockan för aktuell tid läser enhetens systemtid. Du kan verifiera detta via DevTools-fliken Nätverk; verktyget körs helt på klientsidan och fungerar helt offline efter att det laddats.