Det skal du vide
Kort efter midnat i Seoul kan det være den foregående morgen i New York. Samme øjeblik har forskellige lokale datoer: læg ikke selv en dag til. Del dato og klokkeslæt sammen.
Trin i værktøjet
I Lokal dato og tid angiver du kildens lokale dato og tid, ikke målets. Vælg Fra tidszone og Til tidszone fra de tilgængelige zoner, og tryk Beregn. Det er ikke fritekst til alle IANA-navne eller regning med fast tidsforskel.
Kontrolleret eksempel
2026-01-15 00:30 i Asia/Seoul gav Jan 14, 2026, 10:30 · America/New_York: den 14., ikke 15. Python ZoneInfo bekræftede det uafhængigt. Kopiér hele resultatet, og kontrollér datoen i kalenderen.
| Input | Output |
|---|---|
2026-01-15 00:30 · Asia/Seoul | 2026-01-14 10:30 · America/New_York |
2026-01-15 12:00 · America/New_York | 2026-01-15 17:00 · UTC |
2026-07-15 12:00 · America/New_York | 2026-07-15 16:00 · UTC |
Kontrollér resultatet
America/New_York 2026-01-15 12:00 gav UTC 17:00; 2026-07-15 12:00 gav UTC 16:00. Sæsonforskydningerne er forskellige. Brug ikke januars forskel i juli, og antag ikke samtidige omstillinger overalt. Browserens tidszonedata bruges.
Hvis noget går galt
I New York findes 2026-03-08 02:30 ikke, og 2026-11-01 01:30 forekommer to gange. Begge blev afvist uden gæt. Bekræft entydig lokal tid med arrangøren eller brug et kendt UTC-tidspunkt. Kontrollér ellers kildedato og begge zoner.
Ofte stillede spørgsmål
Skal et resultat på dagen før ændres til i dag?
Nej. Kontrollér felterne; resultatet kan være korrekt.
Hvorfor er vinter og sommer én time forskellige?
Zonen bruger forskellige sæsonforskydninger på testdatoerne.
Vælger værktøjet en gentaget tid for mig?
Nej. Tvetydige eller ikke-eksisterende lokaltider afvises.
Begrænsninger
Ingen planlægger til gentagne møder. Kun tilgængelige zoner og datoer; afhænger af browserens tidszonedata.