Wichtige Grundlagen
Kurz nach Mitternacht in Seoul kann es in New York noch Vormittag des Vortags sein. Beides bezeichnet denselben Zeitpunkt: nicht eigenmächtig einen Tag addieren. Datum und Uhrzeit gemeinsam weitergeben.
Schritte im Werkzeug
In Ortsdatum und Uhrzeit die lokale Zeit des Ursprungs, nicht des Ziels eingeben. Ausgangszeitzone und Zielzeitzone aus den verfügbaren Zonen wählen und Berechnen drücken. Kein Freitextfeld für beliebige IANA-Namen und keine Rechnung mit pauschalem Stundenabstand.
Geprüftes Beispiel
2026-01-15 00:30 in Asia/Seoul ergab Jan 14, 2026, 10:30 · America/New_York: den 14., nicht 15. Python ZoneInfo bestätigte dies unabhängig. Vollständiges Ergebnis kopieren und das Datum im Kalender nochmals prüfen.
| Eingabe | Ausgabe |
|---|---|
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 |
Ergebnis prüfen
America/New_York 2026-01-15 12:00 ergab UTC 17:00; 2026-07-15 12:00 ergab UTC 16:00. Die saisonalen Abstände unterscheiden sich. Januarwerte nicht für Juli übernehmen und keine weltweit gleichzeitigen Umstellungen voraussetzen. Die Daten stammen aus dem Browser.
Bei Problemen
In New York existiert 2026-03-08 02:30 nicht; 2026-11-01 01:30 kommt zweimal vor. Beide Eingaben wurden ohne Raten abgelehnt. Eindeutige Ortszeit mit dem Veranstalter klären oder einen bestätigten UTC-Zeitpunkt verwenden. Sonst Ursprungsdatum und beide Zonen prüfen.
Häufige Fragen
Soll ich ein Ergebnis am Vortag auf heute ändern?
Nein. Eingaben prüfen; das Ergebnis kann richtig sein.
Warum unterscheiden sich Winter und Sommer um eine Stunde?
Für die geprüften Daten gelten unterschiedliche saisonale Abstände.
Wählt das Werkzeug eine doppelte Uhrzeit aus?
Nein. Mehrdeutige oder nicht vorhandene Ortszeiten werden abgelehnt.
Grenzen
Kein Planer für wiederkehrende Termine. Nur verfügbare Zonen und unterstützte Daten; abhängig von Browser-Zeitzonendaten.