Artikel

Planlægning af møder på tværs af tidszoner

At vælge et mødetidspunkt der passer for folk i tre byer lyder enkelt indtil klokkerne skifter og alle møder op en time for sent. Denne guide gennemgår mekanikken bag UTC-offset, forklarer hvorfor sommertid er den primære kilde til planlægningsfejl og viser en gentagelig metode til at finde et vindue der falder i arbejdstiden for alle deltagere.

Skrevet af Bastien Sulyan · Udgivet den 28. juni 2026

UTC og offset: grundlaget

Koordineret Universel Tid (UTC) er det fælles referencepunkt for al civil tid. Hver tidszone udtrykkes som UTC plus eller minus et antal timer og minutter. New York om vinteren er UTC-5, Paris om vinteren er UTC+1, Tokyo er UTC+9. Når du skriver et tidspunkt i UTC, kan alle overalt konvertere det til deres lokale ur uden at gætte. De fleste offset er hele timer, men ikke alle. Indien kører ved UTC+5:30, hvilket tilføjer en halvtime der ofte overrasker folk. Nepal går videre ved UTC+5:45, et 45-minutters offset der eksisterer af historiske og politiske årsager. Dele af Australien bruger UTC+9:30 og UTC+10:30. Når du ser en tidszone angivet som et heltalsbased offset, tjek: der kan være en sub-times zone i samme region. Den praktiske regel er at forankre hvert kalenderinvitation i UTC. Lokale tider skifter to gange om året i mange lande; UTC gør ikke.

Diagram der viser UTC i centrum med offset-pile der peger mod byure på forskellige kontinenter, herunder en +5:30-pil for Indien og en +5:45-pil for Nepal

Sommertid: hvorfor offset skifter

Sommertid (DST) fremrykker klokkerne med en time om foråret og sætter dem tilbage om efteråret, hvilket skifter et lands UTC-offset med en time i flere måneder. USA skifter klokker den anden søndag i marts og den første søndag i november. Det meste af Europa skifter den sidste søndag i marts og den sidste søndag i oktober. Australien, der er på den sydlige halvkugle, skifter i oktober og april. Mange lande, herunder Japan, Indien, Kina og det meste af Afrika og Sydøstasien, overholder slet ingen sommertid. Resultatet er en periode på to til tre uger i marts og oktober hvor forskellen mellem to byer ikke er det tal du har husket. New York til London er normalt fem timer fra hinanden; i disse to til tre uger i marts er det fire, fordi USA allerede har skiftet sine klokker og Storbritannien endnu ikke har. Det er den primære kilde til planlægningsfejl i internationale kalendere. Den eneste sikre strategi er at verificere offset på den specifikke dato for mødet, ikke det offset du husker fra sidste måned.

At finde et overlappende vindue

Skriv UTC-offset for hver deltagers placering ned på mødedagen. Tegn derefter en række for hver by og markér hvilke UTC-timer der svarer til den bys 09:00 til 18:00 vindue. Skæringen af alle rækker er din kandidatslot. Et konkret eksempel: New York (UTC-5 om vinteren), London (UTC+0) og Mumbai (UTC+5:30). London 09:00 er UTC 09:00, New York 09:00 er UTC 14:00, Mumbai 18:00 er UTC 12:30. Vinduerne overlapper ikke på tværs af alle tre byer: London og New York deler UTC 14:00 til 17:00 (London 14:00-17:00 og New York 09:00-12:00), men Mumbais arbejdsdag er allerede slut ved UTC 12:30, længe før det vindue åbner. Nogen vil blive nødt til at acceptere en slot uden for normal arbejdstid. Denne slags beregning er præcis hvad timezone-difference-værktøjet på dette website håndterer. Giv det to byer og en dato og det viser offset og om den dato falder i et DST-overgangsvindue.

Gitter med tre rækker mærket New York, London og Mumbai, med skraverede arbejdstidsbands der viser hvor overlapvinduet falder på en UTC-tidslinje

Praktiske vaner for tilbagevendende møder

Angiv tidszonen i hver invitation. At skrive "15:00" er tvetydigt; at skrive "15:00 UTC" eller "15:00 CET (UTC+1)" fjerner gætteriet. Kalenderapplikationer oversætter dette til hver modtagers lokale tid, men kun hvis zonen er eksplicit. For et engangsmøde skal du verificere UTC-offset for den specifikke dato på timezone-converter-værktøjet inden du sender invitationen. For et tilbagevendende ugentligt møde skal du kontrollere hvad der sker ved hver DST-overgangsdato. Et møde fastsat til "10:00 New York-tid" vil skifte med en time i forhold til London-deltagere to gange om året. Enten accepter dette skift og giv deltagerne besked i god tid, eller fastlæg mødet i UTC og lad alles kalender konvertere det lokalt. En simpel konvention brugt af mange distribuerede teams: planlæg alt i UTC, inkluder lokale ækvivalenter for de to eller tre mest repræsenterede zoner i invitationsteksten og tilføj en kalendernotat to uger inden hvert DST-overgangsskift der minder deltagerne om at den lokale tid vil ændre sig. Verdensur-værktøjet lader dig kontrollere flere byer på én gang mod den nuværende UTC-tid, hvilket er nyttigt til en hurtig kontrol inden afsendelse.

Gøre det lokalt i browseren

De tre værktøjer der understøtter denne artikel kører udelukkende i din browser. Ingen tidsdata, ingen bynavne og ingen planlægningsdetaljer forlader din enhed. Timezone-converter-værktøjet tager en dato, et tidspunkt og en kildezone og konverterer det til en eller flere målzoner. Det tager højde for sommertid på den dato du angiver, så det offset det viser afspejler det faktiske offset den pågældende dag, ikke standardoffset for zonen. Verdensur-værktøjet viser den aktuelle tid i flere byer side om side. Det er den hurtigste måde at svare på "hvad er klokken i Singapore lige nu" uden at åbne en søgemaskine. Timezone-difference-værktøjet beregner timeforskellen mellem to zoner på en given dato. Fordi det er datoarelt, håndterer det korrekt de overgangsuger hvor de to zoner endnu ikke begge har skiftet. Alle tre værktøjer fungerer offline når siden er indlæst. Beregningerne bruger IANA-tidszonedatabasen der er bundlet med din browser, så DST-reglerne er så aktuelle som din browserversion.

Værktøjer i denne artikel

Ofte stillede spørgsmål

Hvorfor ændres offset mellem to byer i marts selv om ingen af byerne ændrede tidszone?

De skiftede klokker på forskellige datoer. Når et land anvender sit DST-skift og det andet endnu ikke har, mindskes eller vokser forskellen mellem dem med en time for de mellemliggende dage. Dette løser sig når begge lande har gennemført deres overgang.

Indien er ved UTC+5:30. Overholder det sommertid?

Nej. Indien har ikke overholdt sommertid siden 1945. UTC+5:30-offset er konstant hele året. Nepal, ved UTC+5:45, overholder heller ikke sommertid. Det gør planlægning med sydasia-deltagere mere forudsigelig end planlægning med europæiske eller nordamerikanske.

Er det bedre at sende en mødeindkaldelse i UTC eller i organisatorens lokale tid?

UTC er sikrere til internationale møder. De fleste kalenderapplikationer viser indkaldelsen i modtagerens lokale tid hvis kildezonen er angivet, og UTC skifter aldrig. Sender du en indkaldelse i en sommertidsobserverende zone som Eastern Time, kan modtagere i zoner der skifter på en anden dato se den forkerte lokale tid i ugerne omkring en overgang.