Titel, Ort, Datum und Uhrzeit, Zeitzone, Wiederholung, Eingeladene, Erinnerungen und Notizen — laden Sie dann die .ics-Datei herunter oder öffnen Sie sie direkt in Ihrem Kalender. Sie können auch einen Terminplan einfügen oder ein Dokument oder Foto anhängen, um mehrere Termine auf einmal zu erstellen.
Warum ist mein Kalenderereignis eine Stunde oder einen Tag daneben?
Eine .ics-Datei kann eine Uhrzeit auf drei Arten angeben, und die falsche ist fast immer die Ursache. Eine schwebende Zeit (DTSTART:20260815T090000, keine Zeitzone) ist neun Uhr, wo auch immer sie geöffnet wird. Eine UTC-Zeit (ein angehängtes Z) ist ein absoluter Zeitpunkt. Eine benannte Zeitzone (DTSTART;TZID=Europe/London:...) ist ein Zeitpunkt, der über die Sommerzeitumstellung hinweg auf derselben lokalen Uhrzeit bleibt. Ein um eine Stunde falscher Import ist meist ein Windows-artiger Zeitzonenname wie „GMT Standard Time“, den der lesende Kalender nicht erkennt und daher auf UTC zurückfällt; ein um einen Tag falsches ganztägiges Ereignis ist meist ein Mitternachts-Zeitstempel, wo VALUE=DATE nötig gewesen wäre, oder ein Enddatum, das auf den letzten Tag statt auf den Tag danach geschrieben wurde, da DTEND exklusiv ist. ICS Maker schreibt standardmäßig eine schwebende Zeit und, wenn eine ausgewählt wird, eine TZID mit einer IANA-Zeitzone – ohne eingebetteten VTIMEZONE-Block, den jeder gängige Kalender ohnehin aus dem Zeitzonennamen selbst auflöst.
Die drei Arten, wie eine Datei das „Wann“ angeben kann
- Schwebend – überhaupt keine Zeitzone
DTSTART:20260815T090000. Neun Uhr morgens, wo auch immer es geöffnet wird. Richtig für einen lokalen Termin, eine Erinnerung oder alles, was durch die eigene Uhr des Lesers definiert ist; falsch in dem Moment, in dem zwei Personen in verschiedenen Ländern sich treffen müssen.- UTC – ein absoluter Zeitpunkt
DTSTART:20260815T090000Z, mit dem angehängtenZ. Ein Moment in der Zeit, umgerechnet in Ortszeit von dem Programm, das ihn öffnet. Eindeutig, verliert aber die Tatsache, dass das Meeting „zehn Uhr in London“ war, sodass eine Sommerzeitumstellung es verschiebt.- Benannte Zeitzone – ein Zeitpunkt, der die Sommerzeitumstellung übersteht
DTSTART;TZID=Europe/London:20260815T090000. Das, was ein wiederkehrendes Meeting braucht: Die Serie bleibt bei zehn Uhr Ortszeit, auch wenn sich der Versatz darunter verschiebt. RFC 5545 verlangt einen passendenVTIMEZONE-Block, der die Zeitversätze dieser Zeitzone daneben definiert.
Dieser Builder schreibt standardmäßig die erste und, wenn Sie eine Zeitzone aus der Liste wählen, die dritte. Diese Voreinstellung ist bewusst gewählt: Ein Zahnarzttermin um neun Uhr soll um neun Uhr sein, und die Zeitzone der Maschine anzuhängen, die zufällig die Datei erstellt hat, ist der Grund, warum ein Ereignis für die Person, die es liest, um eine Stunde danebenliegt.
Er schreibt den TZID ohne eingebetteten VTIMEZONE-Block, was es wert ist zu wissen, bevor Sie die Datei irgendwohin Ungewöhnliches senden. Apple Kalender, Google Kalender, Outlook und Thunderbird führen alle die IANA-Zeitzonendatenbank mit sich und lösen Europe/London allein aus dem Namen auf, sodass der Block mehrere hundert Zeilen umfassen würde, die nur wiederholen, was der Leser bereits weiß. Ein strikter Parser, der nur die in der Datei selbst definierten Zeitzonen auflöst, ist der Fall, in dem sich dieser Kompromiss nicht auszahlt – fügen Sie in diesem Fall von Hand einen VTIMEZONE-Block ein, wenn Sie einen solchen Parser beliefern.
Eine falsch angekommene Datei lesen
Öffnen Sie sie in einem Texteditor und schauen Sie sich die Zeile DTSTART an, denn dort steht immer die Antwort. Ein angehängtes Z mit einem Versatz, den Sie nicht erwartet haben, bedeutet, dass der Absender aus einer Zeitzone in UTC umgerechnet hat, die Sie nicht teilen. Ein TZID, das etwas wie GMT Standard Time statt Europe/London benennt, ist die Schreibweise von Microsoft Exchange, und Kalender, die nur die IANA-Namen kennen, fallen dann möglicherweise auf UTC zurück – das ist der klassische, um eine Stunde falsche Import. Ein TZID, das eine Zeitzone benennt, die weder ein IANA-Name ist noch durch einen VTIMEZONE-Block in derselben Datei definiert wird, ist der Fall, bei dem jeder Leser anders rät und dabei oft genug UTC errät, sodass das der zweite Punkt ist, den man prüfen sollte.
Das ganztägige Ereignis, das um einen Tag wandert
Ein ganztägiges Ereignis ist ein Datum, keine Uhrzeit: DTSTART;VALUE=DATE:20260815. Als Mitternachts-Zeitstempel geschrieben, wird es stattdessen zu einem echten Zeitpunkt, und jede Umrechnung nach Westen zieht es in den Vortag. Das Enddatum ist die andere Hälfte der Falle – es ist exklusiv, sodass ein einzelner Tag am 15. am 16. endet, und eine Datei, die ihn am 15. enden lässt, in manchen Kalendern überhaupt nichts anzeigt.
Fragen
- Warum ist mein Kalenderereignis eine Stunde daneben?
- Fast immer eine Sommerzeit-Diskrepanz: Die Datei nennt einen festen UTC-Versatz oder einen Windows-artigen Zeitzonennamen, den der lesende Kalender nicht erkennt, und der Leser fällt auf UTC zurück. Prüfen Sie die DTSTART-Zeile – endet sie auf Z, ist die Zeit absolutes UTC, und trägt sie eine TZID, muss diese Zeitzone als IANA-Name wie Europe/Paris geschrieben sein, oder sonst durch einen VTIMEZONE-Block in derselben Datei definiert werden. Gängige Kalender lösen den IANA-Namen aus ihrer eigenen Kopie der Zeitzonendatenbank auf und benötigen keinen solchen Block.
- Sollte ich eine Zeitzone festlegen oder weglassen?
- Lassen Sie sie weg, wenn das Ereignis durch die lokale Uhrzeit definiert ist – ein Termin, eine Erinnerung, ein Kurs, der um neun Uhr beginnt, egal wo Sie sind. Legen Sie eine fest, wenn das Ereignis zu einem einzigen Zeitpunkt stattfindet, den Gäste in anderen Zeitzonen umrechnen müssen, etwa ein Anruf, ein Webinar oder eine Übertragung.
- Was ist eine schwebende Zeit?
- Eine Datum-Uhrzeit-Angabe ohne Zeitzone und ohne angehängtes Z, die laut RFC 5545 als Ortszeit dort zu interpretieren ist, wo sie gelesen wird. Sie ist häufiger die richtige Wahl, als man denkt, und die falsche, sobald zwei Leser in unterschiedlichen Zeitzonen sich auf einen Zeitpunkt einigen müssen.
- Warum erscheint mein ganztägiges Ereignis am falschen Tag?
- Weil es als Zeitstempel um Mitternacht statt als Datumswert geschrieben wurde. Ein echtes ganztägiges Ereignis verwendet VALUE=DATE ohne jede Uhrzeit, sodass es nichts umzurechnen gibt. Denken Sie auch daran, dass das Enddatum exklusiv ist: Ein eintägiges Ereignis am 15. hat DTEND am 16.