ToolDeck

Timezone Converter

Konvertera datum och tid mellan tidszoner världen över

UTCUTC+00:00

04/16/2026, 21:56:00

America/New_YorkUTC-04:00

04/16/2026, 17:56:00

Vad är tidszonskonvertering?

En tidszonskonverterare översätter ett datum och en tid från en tidszon till en annan, så att du omedelbart kan se vad motsvarande tid är var som helst i världen. Världen är indelad i 24 primära tidszoner, var och en definierad som en fast förskjutning från Coordinated Universal Time (UTC). När klockan är 14:00 UTC är den 09:00 i New York (UTC-5) och 23:00 i Tokyo (UTC+9). För att konvertera mellan tidszoner korrekt krävs kännedom om UTC-förskjutningen för både käll- och målzonen, samt om sommartid (DST) gäller för någon av dem.

IANA Time Zone Database (ofta kallad Olson-databasen eller tz-databasen) är den standardkälla för tidszonsdefinitioner som används av operativsystem, programmeringsspråk och webbläsare. Den tilldelar varje zon ett kanoniskt identifierare i formatet Region/Stad, till exempel America/New_York eller Asia/Tokyo. Till skillnad från fasta förkortningar som EST eller PST kodifierar IANA-identifierare den fullständiga historiken för UTC-förskjutningsändringar och sommartidsövergångar för varje region, vilket gör dem till det enda tillförlitliga sättet att konvertera tid över datum i det förflutna eller framtiden.

Denna tidszonskonverterare använder IANA-tidszondata som är inbyggd i din webbläsares JavaScript-motor via Intl-API:et. Du väljer en källtidszon, anger ett datum och en tid, och verktyget beräknar omedelbart motsvarande tid i din måltidszon, inklusive eventuella sommartidsjusteringar. Eftersom allt körs i din webbläsare sker ingen serveranrop och ingen data lämnar din enhet.

Varför använda denna tidszonskonverterare?

Manuell tidszonsräkning är felbenägen, särskilt när sommartid är inblandad. En stad som är UTC-5 i januari kan vara UTC-4 i juli, och övergångsdatumen skiljer sig mellan länder. USA och Europa ställer om klockorna på olika söndagar, vilket skapar ett tvåveckors fönster då förskjutningen mellan New York och London avviker från resten av året. Det här verktyget hanterar alla dessa övergångar automatiskt med hjälp av samma IANA-databas som ditt operativsystem använder.

~
Omedelbar konvertering
Välj två tidszoner, ange en tid och se resultatet direkt. Inga formulärinlämningar, ingen sidomladdning. Konverteringen uppdateras medan du skriver.
~
Sommartidsmedveten beräkning
Konverteraren hanterar sommartidsövergångar automatiskt. Den använder webbläsarens inbyggda IANA-tidszondata, så resultaten återspeglar korrekt förskjutning för vilket datum du än anger, i det förflutna eller framtiden.
~
Integritetsfokuserad bearbetning
All konvertering sker lokalt i din webbläsare via Intl-API:et. Inga datum, tider eller tidszonsval skickas till någon server.
~
Inget konto krävs
Använd konverteraren utan att registrera dig, installera programvara eller bevilja behörigheter. Öppna sidan, konvertera din tid och stäng den.

Användningsfall för Timezone Converter

Schemaläggning mellan team
När ditt team sträcker sig över New York, Berlin och Singapore kräver det att hitta en mötestid som fungerar för alla att konvertera över tre eller fler tidszoner. Ange en föreslagen tid i din lokala tidszon och se omedelbart om motsvarande tid på varje teammedlems plats faller inom deras arbetstid.
Felsökning av API-tidsstämplar
API-svar innehåller ofta tidsstämplar i UTC eller en serverns lokala tidszon. Konvertera dessa tidsstämplar till din lokala tid för att verifiera att händelser inträffade när de förväntades och att tidsbaserad logik är korrekt.
Incidenttidslinjer i DevOps
Under en incident kan loggposter komma från servrar i olika regioner. Konvertera alla tidsstämplar till en enda referenstidszon (vanligtvis UTC) för att bygga en korrekt tidslinje för händelserna.
QA-testning av datumlogik
Applikationer som visar datum för användare i olika regioner behöver testas med specifika tidszoner som indata. Använd konverteraren för att generera testfall för gränssituationer som sommartids-"spring forward"-timmen.
Koordinering av datapipelines
ETL-jobb som är schemalagda i en tidszon kan behöva matcha schemat för datakällor eller nedströmsanvändare i en annan. Konvertera schemalagda körningstider för att verifiera att pipeline-stegen körs i rätt ordning.
Lärande om tidszonskoncept
Studenter som lär sig om UTC-förskjutningar, den internationella datumlinjen och sommartidsregler kan experimentera med olika tidszonspar för att se hur tiden förskjuts mellan regioner.

IANA-tidszonsreferens

IANA Time Zone Database definierar över 400 tidszonsidentifierare och uppdateras ett flertal gånger per år för att återspegla politiska förändringar, nya sommartidsregler och historiska korrigeringar. Tabellen nedan listar de vanligaste zonerna med deras standardmässiga UTC-förskjutningar och sommartidsbeteende. Förskjutningar visas för normaltid; DST-kolumnen visar den justerade förskjutningen när sommartid gäller för den regionen.

IANA-identifierareVanligt namnUTC-förskjutningDST
UTCCoordinated Universal Time+00:00No
America/New_YorkEastern Time (US)-05:00Yes (EDT -04:00)
America/ChicagoCentral Time (US)-06:00Yes (CDT -05:00)
America/DenverMountain Time (US)-07:00Yes (MDT -06:00)
America/Los_AngelesPacific Time (US)-08:00Yes (PDT -07:00)
Europe/LondonGreenwich Mean Time+00:00Yes (BST +01:00)
Europe/BerlinCentral European Time+01:00Yes (CEST +02:00)
Europe/MoscowMoscow Time+03:00No
Asia/DubaiGulf Standard Time+04:00No
Asia/KolkataIndia Standard Time+05:30No
Asia/ShanghaiChina Standard Time+08:00No
Asia/TokyoJapan Standard Time+09:00No
Australia/SydneyAustralian Eastern Time+10:00Yes (AEDT +11:00)
Pacific/AucklandNew Zealand Standard Time+12:00Yes (NZDT +13:00)

Kodexempel

Alla större programmeringsspråk tillhandahåller tidszonskonvertering via IANA-databasen. Exemplen nedan visar hur man konverterar en UTC-tidsstämpel till andra tidszoner i JavaScript med Intl-API:et, Python med zoneinfo-modulen, Go med time-paketet och GNU date-kommandot för skalskript.

JavaScript (Intl API)
// Convert a date from one timezone to another
const date = new Date('2026-03-15T09:00:00Z')

// Format in specific timezone
const nyTime = date.toLocaleString('en-US', { timeZone: 'America/New_York' })
// → "3/15/2026, 5:00:00 AM"

const tokyoTime = date.toLocaleString('en-US', { timeZone: 'Asia/Tokyo' })
// → "3/15/2026, 6:00:00 PM"

// Get the UTC offset for a timezone programmatically
function getUtcOffset(tz: string, date = new Date()) {
  const fmt = new Intl.DateTimeFormat('en-US', {
    timeZone: tz,
    timeZoneName: 'longOffset',
  })
  const parts = fmt.formatToParts(date)
  return parts.find(p => p.type === 'timeZoneName')?.value ?? ''
}
getUtcOffset('Asia/Kolkata') // → "GMT+05:30"
Python (zoneinfo + datetime)
from datetime import datetime
from zoneinfo import ZoneInfo

# Create a timezone-aware datetime
dt = datetime(2026, 3, 15, 9, 0, tzinfo=ZoneInfo('UTC'))

# Convert to New York time
ny = dt.astimezone(ZoneInfo('America/New_York'))
print(ny)  # → 2026-03-15 05:00:00-04:00 (EDT in March)

# Convert to Tokyo time
tokyo = dt.astimezone(ZoneInfo('Asia/Tokyo'))
print(tokyo)  # → 2026-03-15 18:00:00+09:00

# Get current time in any timezone
now_berlin = datetime.now(ZoneInfo('Europe/Berlin'))
print(now_berlin.strftime('%Y-%m-%d %H:%M %Z'))  # → 2026-03-15 10:00 CET
Go
package main

import (
	"fmt"
	"time"
)

func main() {
	utc := time.Date(2026, 3, 15, 9, 0, 0, 0, time.UTC)

	// Load timezone by IANA name
	ny, _ := time.LoadLocation("America/New_York")
	tokyo, _ := time.LoadLocation("Asia/Tokyo")

	fmt.Println(utc.In(ny))    // → 2026-03-15 05:00:00 -0400 EDT
	fmt.Println(utc.In(tokyo)) // → 2026-03-15 18:00:00 +0900 JST

	// Get the UTC offset in seconds
	_, offset := utc.In(ny).Zone()
	fmt.Printf("UTC offset: %+d hours\n", offset/3600) // → UTC offset: -4 hours
}
CLI (GNU date / TZ variable)
# Display current time in a specific timezone
TZ='Asia/Tokyo' date '+%Y-%m-%d %H:%M:%S %Z'
# → 2026-03-15 18:00:00 JST

# Convert a UTC timestamp to another timezone
TZ='America/Los_Angeles' date -d '2026-03-15T09:00:00Z' '+%Y-%m-%d %H:%M %Z'
# → 2026-03-15 02:00 PDT

# List all available IANA timezone names
timedatectl list-timezones | head -20

Vanliga frågor

Vad är skillnaden mellan UTC och GMT?
UTC (Coordinated Universal Time) och GMT (Greenwich Mean Time) representerar i praktiken samma tid: noll förskjutning från nollmeridianen. Skillnaden är teknisk. UTC definieras av atomklockor och är den globala tidsstandard som används inom datavetenskap. GMT är ett tidszonsnamn kopplat till Storbritannien. Använd alltid UTC som referenspunkt i kod, inte GMT.
Hur påverkar sommartid tidszonskonvertering?
När en region tillämpar sommartid förskjuts dess UTC-offset med en timme (ibland 30 eller 45 minuter) under en del av året. Till exempel är America/New_York UTC-5 på vintern (EST) och UTC-4 på sommaren (EDT). Om du hårdkodar en förskjutning i stället för att använda en IANA-tidszonsidentifierare kommer dina konverteringar att vara fel under halva året. Använd alltid det fullständiga IANA-namnet som America/New_York, inte en fast förskjutning.
Varför ska jag använda IANA-tidszonsnamn i stället för förkortningar som EST eller PST?
Tidszonsförkortningar är tvetydiga. CST kan betyda Central Standard Time (UTC-6), China Standard Time (UTC+8) eller Cuba Standard Time (UTC-5). IANA-identifierare som America/Chicago är globalt unika och kodifierar den fullständiga historiken för förskjutningsändringar och sommartidsregler för den regionen. IANA-databasen underhålls av Internet Assigned Numbers Authority och uppdateras ett flertal gånger per år.
Vad händer med en tid som faller i sommartids-"spring forward"-gapet?
När klockorna ställs fram hoppas en timme över. I America/New_York hoppar till exempel klockan 02:00 direkt till 03:00 den andra söndagen i mars. En tid som 02:30 finns inte på det datumet i den tidszonen. De flesta programmeringsspråk hanterar detta genom att flytta fram tiden till 03:00 eller generera ett fel, beroende på biblioteket.
Kan jag konvertera tider för historiska datum korrekt?
Ja, om du använder IANA-tidszonsidentifierare. IANA-databasen innehåller historiska förskjutningsändringar som sträcker sig decennier tillbaka. Exempelvis använde Kina fem tidszoner före 1949 och bytte sedan till en enda zon (UTC+8). Databasen registrerar dessa övergångar, så konvertering av en tidsstämpel från 1945 för Asia/Shanghai använder den korrekta historiska förskjutningen.
Hur lagrar jag tider i en databas för att undvika tidszonsproblem?
Lagra alla tidsstämplar i UTC. När du visar en tid för en användare konverterar du från UTC till användarens lokala tidszon vid renderingstillfället. Det här tillvägagångssättet undviker tvetydighet: en UTC-tidsstämpel har exakt en betydelse oavsett var servern eller användaren befinner sig. PostgreSQL:s TIMESTAMPTZ-typ och MySQL:s TIMESTAMP-typ lagrar båda värden i UTC internt.
Finns det en tidszon med 30 eller 45 minuters förskjutning?
Ja. India Standard Time (Asia/Kolkata) är UTC+5:30, Nepal Standard Time (Asia/Kathmandu) är UTC+5:45 och Chathamöarna (Pacific/Chatham) är UTC+12:45. Iran (Asia/Tehran) använder UTC+3:30. Dessa bråkdelade förskjutningar innebär att man inte kan anta att alla tidszonsskillnader är hela timmar när man skriver konverteringslogik.