De duurste vergadering die ik ooit gemist heb stond goed gepland Iemand in Londen zette & quot;3pm mijn tijd, 10am yours" in een kalender uitnodiging aan mij in New York, wat waar was toen ze het in februari schreven Het telefoontje was op 12 maart De Verenigde Staten hadden de vorige zondag zijn klokken naar voren verplaatst; het Verenigd Koninkrijk had niet, en zou het niet voor nog eens drie weken Het gat tussen Londen en New York, normaal vijf uur, was vier die week - dus 15h in Londen was voor mij 11h0, niet 10h Ik kwam een uur te vroeg bij een lege kamer, gaf het op, en miste de oproep helemaal.
Dat drie weken durende venster in het voorjaar - en het één week durende venster in het najaar - is geen randgeval Het gebeurt elk afzonderlijk jaar, en het vangt mensen op die anders volkomen bekwaam zijn in rekenen, omdat de rekenkunde niet het probleem is Het probleem is dat & quot; Londen is vijf uur voorsprong op New York" het gaat niet om twee steden Het is een feit over twee steden Op een bepaalde datum, en het moment dat je het opschrijft zonder de datum die eraan is gekoppeld, heb je een bug gemaakt.
Een tijdzone is geen verschuiving. Het is een set regels die een offset produceren wanneer u het een moment voedt. Die regels veranderen: landen nemen daglicht aan, verlaten het, verschuiven hun standaard offset of kunnen een permanente wijziging aankondigen met een kennisgeving van drie weken. Dit is waarom de tijdzone-omzetter in Toolz.dev slaat nergens een offset op. 't Vraagt de IANA tijdzonedatabase - degene die al in uw browser zit - wat de offset is voor het exacte moment dat u converteert, en er wordt opnieuw om elk ander moment gevraagd.
tl;dr: De kloof tussen twee zones hangt af van de datum, omdat zomertijdtransities niet tussen landen liggen. de tijdzone-omzetter Lost elke verschuiving via de IANA-database op voor het specifieke moment dat u invoert, toont zowel UTC-offsets als het ondertekende verschil, behandelt zones van een half uur en kwartier en legt hetzelfde moment in verschillende steden in een vergaderplannerstrook. Het draait volledig in uw browser.
Belangrijkste kenmerken
Offsets opgelost per moment, nooit hard gecodeerd
Elke offset in deze tool wordt berekend door uw instant in de doelzone te formatteren en de wandklok terug te lezen. Die ene ontwerpbeslissing betekent zomertijd, wijzigingen in historische regels en landen die hun offset aanpassen bij een overheidsdecreet worden allemaal afgehandeld via hetzelfde codepad. Er is geen offsettabel om bij te houden en geen tafel om verouderd te raken. Converteer een bijeenkomst in januari en dezelfde bijeenkomst in juli tussen Berlijn en Chicago, en de tool geeft je beide keren correct een pauze van zeven uur - maar converteer er eind maart één en het geeft je er correct zes.
Meer dan 50 samengestelde IANA-zones
De kiezer vermeldt de steden die mensen daadwerkelijk plannen, gegroepeerd per regio, gelabeld met hun land en naast de volledige IANA-identificatie worden weergegeven. Dat laatste deel is belangrijker dan het lijkt: Asia/Kolkata is de tekenreeks die je in een cron-expressie plakt, een postgres AT TIME ZONE clausule, of een python ZoneInfo constructeur. Lezen "Kolkata, India" en kopiëren Asia/Kolkata zijn twee verschillende taken, en de tool doet beide.
Een vergaderplannerstrip
Onder de conversie krijgt elke zone die u toevoegt een rij uurcellen die het venster rond uw moment overspant. Werktijden (09:00 tot 17:59 lokaal) zijn gearceerd, vroeg en laat worden afzonderlijk gemarkeerd en elke cel die op een andere kalenderdag valt, draagt een +1d of -1d badge. Het vinden van een uur dat tegelijkertijd beschaafd is in San Francisco, Londen en Sydney is een moeilijk probleem: de strip maakt het visueel in plaats van rekenkundig.
Zones van een half uur en kwartier behandeld als normaal
India is UTC+05:30. Nepal is UTC+05:45. Adelaide is UTC+09:30 in de winter en UTC+10:30 in de zomer. De Chatham-eilanden zijn UTC+12:45. Ongeveer een vijfde van de wereldbevolking leeft op een compensatie die niet een heel aantal uren is, en elk hulpmiddel dat anders aanneemt dat het voor honderden miljoenen mensen verkeerd is. Offsets worden hier opgeslagen en weergegeven in minuten.
Afkortingen weergegeven voor de datum die u hebt ingevoerd
Elke zijde van de conversie geeft de zoneafkorting weer die op dat moment van kracht is - EST of EDT, GMT of BST, AEST of AEDT Dit is de snelste manier om te zien op welke zijde van een overgang je bent geland Als je een datum in maart hebt ingevoerd en op de tool staat EDT, zijn de klokken al veranderd Als er EST staat, dan is dat niet het geval.
Volledig klantzijde
Elke berekening wordt uitgevoerd in JavaScript in uw browser, met behulp van de Intl API en de tijdzonedatabase die bij de engine wordt geleverd. Er wordt niets geüpload, niets wordt gelogd en zodra de pagina is geladen, blijft de converter werken zonder netwerkverbinding. Dat betekent ook dat het resultaat wordt bijgewerkt op het moment dat u een veld wijzigt, omdat er geen rondreis is om op te wachten.
Hoe de tijdzone-omzetter te gebruiken
Stap 1: Stel de bronzone, datum en tijd in
Kies de stad die je aan het converteren bent ten gevolge van, voer dan de datum en de tijd in precies zoals de klok daar leest. Het tijdveld neemt een waarde van 24 uur, dus 15:00 uur is 15:00. Als u het huidige moment wilt in plaats van een hypothetisch moment, drukt u op als- het laadt de huidige datum en tijd zoals te zien in de bronzone, wat niet noodzakelijkerwijs dezelfde datum is als die aan je eigen muur.
Stap 2: Kies de doelzone
Kies de stad waarin je het antwoord wilt. De omgerekende datum, tijd en 12 uur lezen verschijnen onmiddellijk, samen met de UTC-offset en afkorting die op die specifieke datum van toepassing zijn. Merk op dat de dateren Kan veranderen: maandag 21:00 uur in New York is dinsdag 7:00 uur in Dhaka, en de tool toont de nieuwe datum in plaats van stilletjes je te laten werken.
Stap 3: Lees de offsets en de kloof
Onder elke kant krijg je de offset in UTC±HH:MM formulier en de zoneafkorting Daartussen vermeldt de tool de relatie in woorden - & quot; Dhaka loopt 10 uur voor op New York" - met de juiste waarde voor die datum, geen gememoriseerd gemiddelde Gebruik de swapknop om de richting om te keren; het blijft hetzelfde nadrukkelijk En draait om welke kant je binnengaat, wat je bijna altijd wilt.
Stap 4: Bouw de vergaderstrook
Voeg elke deelnemerzone toe aan de planner. Elke rij toont hetzelfde moment in die zone plus de uren eromheen, met werkuren in de schaduw. Schuif uw brontijd eerder of later en kijk hoe de schaduwbewegingen worden verplaatst. Wanneer de gearceerde cellen in elke rij in lijn zijn, heb je je slot gevonden.
Stap 5: Kopieer het resultaat
Kopieer alleen de geconverteerde tijd, of de volledige expressie - Sun, Mar 12, 2026 09:00 EDT (America/New_York) = Sun, Mar 12, 2026 13:00 GMT (Europe/London)- en plak het in de kalenderuitnodiging Schrijven van beide kanten met hun afkortingen is de meest effectieve gewoonte om mijn Londense fout niet te herhalen.
Hoe tijdzoneconversie eigenlijk werkt
Het naïeve mentale model is dat elke zone een getal heeft en conversie is aftrekken. Dat model is verkeerd op een manier die meestal de juiste antwoorden produceert, wat de slechtst mogelijke faalmodus is.
Het juiste model heeft drie lagen.
Laag één: het moment. Onder alles bevindt zich een enkel punt op de universele tijdlijn - een tijdstempel van het tijdperk, een aantal seconden sinds 1970-01-01T00:00:00Z. Instants zijn ondubbelzinnig Iedereen op aarde ervaart hetzelfde moment tegelijkertijd, wat hun klok ook zegt.
Laag twee: de offset. Een offset is een ondertekend aantal minuten om toe te voegen aan UTC om lokale muurkloktijd te krijgen. UTC-04:00 is een verschuiving. het is een uitkomst, geen eigendom van een plaats.
Laag drie: de zone. Een zone is een benoemde set regels - America/New_York- dat wijst een moment toe aan een offset. Dit is de laag die mensen in laag twee samenvoegen, en die ineenstorting is de bron van bijna elke tijdzonebug die ooit is geschreven.
Dus een conversie is niet localB = localA + delta. het is:
instant = resolve(wallClockA, zoneA) // rules of A, applied to that reading
wallClockB = render(instant, zoneB) // rules of B, applied to that instant
Twee regelzoeken, één moment in het midden. De tool doet precies dit. Om de verschuiving van een zone op een moment op te lossen, formatteert het het moment in die zone, leest het jaar, maand, dag, uur, minuut en tweede, behandelt die velden alsof ze UTC zijn, en trekt het echte moment af. Het verschil is de offset, in minuten, rechtstreeks van de kopie van de engine van de IANA-database.
De andere kant op gaan - van een muurklokmeting tot een moment - heeft een kip-en-ei-probleem, omdat je de offset nodig hebt om het moment en het moment te vinden om de offset te vinden. Het gereedschap raadt een keer met behulp van de naïeve offset, controleert of de gok aan de andere kant van een overgang is geland en corrigeert of dit het geval is. Twee opzoekingen eindigen altijd en corrigeren over de zomertijdgrenzen heen.
De IANA-tijdzonedatabase
De database waar alles van afhankelijk is, wordt onderhouden door Iana en wordt vaak nog steeds de "Olson Database" genoemd naar Arthur David Olson, die het in de jaren tachtig begon. Het wordt binnen elk besturingssysteem, elke browser, elke JVM en elke Python-installatie geleverd, en het wordt meerdere keren per jaar bijgewerkt omdat regeringen van gedachten blijven veranderen.
de identificatiegegevens nemen de vorm aan Area/Locationpiepsel America/New_York, Europe/London, Asia/Kolkata, Australia/Sydney. De locatie is een representatieve stad, geen politieke claim - America/New_York Beslaat de hele oostelijke zone van de VS, en Indiana heeft beroemd een tiental eigen identificaties nodig omdat de provincies het al tientallen jaren oneens waren over het al dan niet observeren van zomertijd.
Wat de database opslaat, is geen enkele offset per zone, maar een volledige regelgeschiedenis. Het weet dat Oekraïne's Europe/Kyiv was Europe/Kiev Totdat de spelling in 2022 werd bijgewerkt. Het weet dat Egypte de zomertijd in 2023 opnieuw introduceerde nadat hij het in 2014 had verlaten. Het weet dat Samoa 30 december 2011 volledig oversloeg toen het de internationale datumlijn sprong. Die geschiedenis is de reden waarom het converteren van een datum in 2015 en een datum in 2025 voor hetzelfde paar steden legitiem verschillende antwoorden kan opleveren, en waarom een tool die offsets offsets hardcodet, een hulpmiddel is dat over het verleden ligt.
Het praktische gevolg voor iedereen die software schrijft: Sla instants op in UTC, sla de gebruikerszone op als een IANA-identificatie en converteer alleen op de weergavelaag. Bewaar nooit een offset. Een offset is een weergave van een regel en regels veranderen. Als u direct met Epoch-waarden werkt, wordt de tijdstempel converter is het begeleidende hulpmiddel om ze terug te lezen als datums.
UTC-offsets, afkortingen en zonenamen: welke te gebruiken
Deze drie dingen worden voortdurend verward en ze zijn niet uitwisselbaar.
| klasse | toonbeeld | stabiel? | Uniek? | Gebruik het voor |
|---|---|---|---|---|
| IANA-zonenaam | America/New_York |
Ja, over de DST | ja | Opslag, code, configuratie, API's |
| UTC-offset | UTC-04:00 |
Nee, wijzigingen met DST | heel weinig | display, draadformaten met een instant bevestigd |
| afkorting | EDT |
Nee, wijzigingen met DST | heel weinig | Alleen op mensen gerichte weergave |
De moordenaar is die laatste kolom. Afkortingen zijn niet uniek. CST betekent Amerikaanse centrale standaardtijd, Chinese standaardtijd en Cuba-standaardtijd - drie verschillende verschuivingen, één string. IST betekent Indiase standaardtijd, Ierse standaardtijd en Israël-standaardtijd. BST betekent Britse zomertijd, en ook Bougainville Standard Time. Als een systeem ontvangt CST Over de draad en moet raden, het zal voor iemand verkeerd raden.
De offsetvorm is ondubbelzinnig maar niet stabiel: UTC+01:00 Identificeert een instant's rendering, maar het is geen zone en u kunt het niet gebruiken om te berekenen naast Dinsdag rendering, want aanstaande dinsdag kan aan de andere kant van een overgang vallen.
Alleen de IANA-naam draagt de regels. Het is de enige van de drie die je ooit zou moeten volhouden.
Waarom de kloof tussen twee steden blijft bewegen
Zomertijd is de reden, en de reden dat het zo hard bijt, is dat landen hun overgangen niet synchroniseren.
- de Verenigde Staten Springt naar voren op de tweede zondag in maart en valt terug op de eerste zondag van november.
- De Europese Unie Springt naar voren op de laatste zondag van maart en valt terug op de laatste zondag van oktober.
- AustraliëOmdat ik op het zuidelijk halfrond ben, doet ik het tegenovergestelde: vooruit in oktober, terug in april - en Queensland, West-Australië en het Northern Territory doen dat helemaal niet.
- India, China, Japan, het grootste deel van Afrika en het grootste deel van Azië Neem het op geen enkel moment in acht.
Stel die op een rij en je krijgt overlappende vensters waar de gebruikelijke kloof gewoon verkeerd is:
| duur | Nieuwe klok | Londense klok | lacune |
|---|---|---|---|
| het grootste deel van de winter | EST (UTC05:00) | GMT (UTC+00:00) | 5 uur |
| Tweede zondag in maart → Laatste zondag in maart | EDT (UTC04:00) | GMT (UTC+00:00) | 4 uur |
| het grootste deel van de zomer | EDT (UTC04:00) | BST (UTC+01:00) | 5 uur |
| Laatste zondag in oktober → Eerste zondag in november | EDT (UTC04:00) | GMT (UTC+00:00) | 4 uur |
Twee vensters per jaar - ruwweg drie weken in het voorjaar en één week in het najaar - waarin elke & quot; we' altijd vijf uur uit elkaar liggen" aanname in je kalender is een uurtje uit En dat is slechts één paar steden Voeg Sydney toe, waarvan de overgangen in de tegenovergestelde richting lopen, en het aantal duidelijke gap-waarden over een jaar stijgt snel.
De overgangen zelf creëren nog twee gevaren die het waard zijn om te noemen. Wanneer klokken vooruit springen, een uur lokale tijd Bestaat niet- 02:30 op de overgangsavond in New York is geen echte lezing Als klokken terugvallen, een uur lokale tijd Gebeurt twee keer, en een kale muurklok lezen is echt dubbelzinnig. De converter lost niet-bestaande tijden op tot het moment onmiddellijk na de overgang en dubbelzinnige tijden naar het eerste voorval, wat de conventie is die de meeste kalendersoftware volgt. Het is niet de enige verdedigbare keuze, maar het is degene die de minste verrassingen produceert.
Veelvoorkomende gebruiksgevallen
Het plannen van vergaderingen in een gedistribueerd team. de voor de hand liggende, en degene waar de plannerstrip voor bestaat. Drie of meer zones is waar de mentale rekenkunde op betrouwbare wijze faalt, vooral wanneer een van hen een offset van een half uur of op het zuidelijk halfrond heeft.
Kalenderuitnodigingen en aankondigingen schrijven. Geef altijd de tijd met een zone, geef altijd ten minste twee weergaven en geef de voorkeur aan de Iana-naam of een volledig gekwalificeerde afkorting boven "Mijn tijd". "14:00 UTC (10:00 EDT / 19:30 IST)" is ondubbelzinnig. "2PM" is een muntstuk.
Debugging tijdstempels in logboeken. Een server logt in UTC, een klant meldt een incident in de lokale tijd en de twee moeten worden verzoend voordat u het verzoek kunt vinden. Converteer het rapport van de klant naar UTC en zoek vervolgens. Als de logboeken tijdperkwaarden zijn in plaats van ISO-tekenreeksen, voer ze dan door de tijdstempel converter eerst.
Planning van cron-banen en achtergrondwerk. Een cron-expressie op een server die is ingesteld op UTC zal niet verschuiven met een gebruiker' s zomertijd verandering, wat meestal is wat u wilt - en af en toe precies wat u niet doet, als de taak bedoeld is om te draaien om 09:00 lokale voor een klant in een DST-observerend land Beide metingen uit te werken voordat u het schema vastlegt; de croonparer zal je vertellen wat je uitdrukking eigenlijk betekent.
Reizen en bellen met familie plannen. Vertrek- en aankomsttijden worden altijd in de lokale tijd gegeven op elke luchthaven, wat betekent dat de schijnbare duur van een vlucht onzin is totdat u beide uiteinden naar dezelfde zone converteert. Een vlucht van 14 uur die "aankomt voordat het vertrekt" is slechts een oversteekplaats voor de date.
Coördineren van lanceringen, inzet en embargo's. Alles met een harde grens over meerdere markten heeft een enkel moment nodig, uitgedrukt in UTC, met lokale weergaven voor elke regio. Als u aan het berekenen bent hoeveel dagen er nog tot dat moment over zijn in plaats van de klok lezen, dan Datumverschil rekenmachine is de andere helft van de workflow.
FAQ
Hoe converteer ik EST naar IST?
chic America/New_York Als bron en Asia/Kolkata als doel. India loopt 10 uur en 30 minuten voor op New York tijdens de oosterse standaardtijd en 9 uur en 30 minuten voor de oostelijke daglichttijd, omdat India geen zomertijd in acht neemt en de Verenigde Staten dat wel doen. Die verschuivingsgat is precies waarom je zou moeten converteren naar een datum in plaats van een enkel getal te onthouden.
Wat is het verschil tussen EST en EDT?
EST (Eastern Standard Time) is UTC05:00 en is van toepassing in de winter. EDT (Eastern Daylight Time) is UTC04:00 en geldt vanaf de tweede zondag in maart tot de eerste zondag in november. In documenten en code, geef de voorkeur aan de IANA-identifier America/New_York, die het hele jaar door ondubbelzinnig is.
Gaat deze converter om met de zomertijd?
Ja, en dat gebeurt voor de datum die u invoert in plaats van voor vandaag. Elke zone's-offset wordt opgelost via de IANA-tijdzonedatabase op het specifieke moment dat u converteert, dus een bijeenkomst op 1 maart en dezelfde bijeenkomst op 15 maart tussen New York en Londen zullen correct een gat van vijf uur en een gat van vier uur laten zien respectievelijk - de Verenigde Staten verplaatsen hun klokken drie weken vooruit voordat Europa dat doet.
Wat is een IANA-tijdzone-ID?
Het is een naam zoals America/New_York, Europe/London, of Asia/Kolkata ontleend aan de IANA tijdzone database, de referentie dataset die niet alleen huidige offsets registreert maar elke historische regelwijziging Identifiers zijn Area/Location paren, en ze zijn de enige veilige manier om een zone te benoemen in software, omdat afkortingen zoals CST dubbelzinnig zijn - US Central, China Standard, en Cuba Standard claimen het allemaal.
Waarom hebben sommige tijdzones een offset van 30 of 45 minuten?
Omdat zones politiek zijn, niet geometrisch. India vestigde zich op UTC+05:30 om een breed land op één klok te besturen. Nepal koos UTC+05:45 om een kwartier voor India te zitten. Adelaide is UTC+09:30 en de Chatham-eilanden zijn UTC+12:45. Elke code die aanneemt dat compensaties hele uren zijn, zal uiteindelijk verkeerd zijn voor ongeveer een vijfde van de wereldbevolking.
Wat is UTC en hoe verschilt het van GMT?
UTC (Coordinated Universal Time) is de atomic-clock standaard die elke zone wordt gedefinieerd als een offset van GMT (Greenwich Mean Time) is een tijdzone die toevallig gelijk is aan UTC+00:00 in de winter - het Verenigd Koninkrijk verhuist naar BST (UTC+01:00) in de zomer, dus "GMT" en & quot; London time" zijn niet het hele jaar hetzelfde Opslaan en vergelijken instants in UTC; converteren naar een zone alleen voor weergave.
Hoeveel tijdzones zijn er in de wereld?
Er zijn in theorie 24 een uur durende bands, maar ongeveer 38 verschillende UTC-offsets worden daadwerkelijk gebruikt zodra zones van half uur en kwartier worden geteld, die UTC12:00 tot UTC+14:00 overspannen. Die 26 uur durende spreiding is de reden waarom twee plaatsen op aarde op hetzelfde moment op verschillende kalenderdatums kunnen staan. De IANA-database zelf definieert zelf enkele honderden benoemde zones, omdat het zowel historische als actuele regels volgt.
Wat gebeurt er met een tijd die in een zomers slaatje valt?
Wanneer klokken naar voren springen, bestaat er nooit een uur lokale tijd, dus 02:30 op de overgangsavond in New York is geen echte lezing De converter lost zo'n invoer onmiddellijk na de overgang op naar het moment in plaats van een verkeerd antwoord geruisloos terug te geven. Tijden in de herfst overlappen elkaar, waarbij dezelfde wandklok twee keer plaatsvindt, besluiten tot de eerste gebeurtenis - de conventie die de meeste kalendersoftware volgt.
