Ich will, dass Termine aus meinen E-Mails von selbst im richtigen Google-Kalender landen, statt dass ich sie abtippe. Bau mir dafür ein Google-Apps-Script. Frag mich zuerst aus — einzeln, nicht als Liste, und warte meine Antwort ab: 1. Welche Kalender ich habe und wofür sie da sind. Sag mir dabei, wo ich die Kalender-ID finde: in Google Kalender links neben dem Kalendernamen auf die drei Punkte, dann „Einstellungen und Freigabe“, und weit unten steht sie. 2. Wonach sortiert werden soll: nach Absenderadresse, nach Wörtern im Betreff, nach der Adresse, an die geschrieben wurde. 3. Bei welchen dieser Regeln auch dann ein Termin entstehen soll, wenn die Mail keinen Kalenderanhang hat und das Datum nur im Fließtext steht. 4. Wie weit zurück gesucht werden soll. 5. In welcher App ich meinen Kalender tatsächlich ansehe: Apple Kalender, Outlook, oder Google Kalender im Browser. Die fünfte Frage ist wichtiger, als sie klingt. Das Skript läuft auf Googles Plattform und kann ausschließlich in einen Google-Kalender schreiben — in einen iCloud-Kalender kommt es nicht hinein. Wer seine Termine sonst in Apple Kalender oder Outlook liest, sieht die Einträge deshalb erst, wenn dort das Google-Konto eingebunden ist. Sag mir das offen, statt es vorauszusetzen, und führ mich durch beides: - wie ich das Google-Konto in meiner Kalender-App hinzufüge und den betreffenden Kalender einblende - wie ich ihn dort zum Standardkalender mache, damit auch die Termine, die ich selbst von Hand anlege, dort landen und nicht in einem zweiten, den das Skript nie sieht Der zweite Punkt ist der, den man sonst erst Wochen später merkt: Die Einträge aus dem Skript stehen im einen Kalender, die eigenen im anderen, und man wundert sich, warum nie alles zusammen an einem Ort steht. Wenn ich gar kein Google-Konto habe, sag mir das gleich am Anfang — dann ist dieser Weg nichts für mich, und ich will es wissen, bevor wir eine Stunde investieren. Wenn ich eine Regel vage beschreibe, frag nach einer echten Mail aus meinem Postfach als Beispiel. „Alles von der Uni“ ist keine Regel, „Absender endet auf @hochschule.de“ ist eine. Dann schreib das Skript. Die folgenden Anforderungen sind nicht verhandelbar — jede davon ist ein Fehler, den man sonst macht: Merk dir, welche Nachrichten du schon verarbeitet hast. Leg die Nachrichten-IDs im PropertiesService ab und überspring bekannte sofort. Ohne das legt jeder Durchlauf dieselben Termine noch einmal an, und bei einem Auslöser alle 15 Minuten ist der Kalender bis zum Abend unbrauchbar. Deckle die Liste auf die letzten paar tausend Einträge, sonst läuft die Eigenschaft irgendwann über. Bau einen Trockenlauf als eigene Funktion. Die protokolliert nur, was sie tun würde — welche Mail, welche Regel greift, welcher Kalender, welches Datum sie gelesen hat — und legt nichts an. Die läuft als Erstes und so lange, bis das Ergebnis stimmt. Ein Skript, das ungeprüft auf einen echten Kalender losgelassen wird, produziert Einträge, die man einzeln von Hand wieder löscht. Lizenz CC BY 4.0 · Vincent Weber · vwincenzo.com Bau eine zweite Funktion, die die gemerkten IDs wieder löscht. Das ist der Notausgang, wenn beim Ausprobieren etwas schiefging. Teil die Gmail-Suche in mehrere kurze Abfragen auf, statt eine lange zu bauen, und führ die Treffer zusammen — dedupliziert über die Thread-Kennung. Lange Suchanfragen schneidet Gmail ab, und du merkst es nicht: Du bekommst einfach weniger Treffer zurück. Zwei Wege, in dieser Reihenfolge. Hat die Mail einen Anhang, dessen Name auf .ics endet oder dessen Typ „calendar“ enthält, lies den Termin daraus — das ist immer genauer. Nur wenn kein solcher Anhang da ist, versuch das Datum aus Betreff und Text zu lesen, und das ausschließlich bei den Regeln, bei denen ich es ausdrücklich erlaubt habe. Ohne diese Einschränkung wird jeder Newsletter mit einer Jahreszahl zu einem Kalendereintrag. Beim Lesen der .ics-Datei entfaltest du zuerst die Zeilen. Das Format bricht lange Zeilen um und setzt sie mit einem führenden Leerzeichen oder Tabulator fort. Wer das nicht rückgängig macht, bekommt abgeschnittene Titel und halbe Beschreibungen. Ganztägige Termine: Das Enddatum im ICS ist exklusiv, es bezeichnet den Tag danach. Zieh einen Tag ab, sonst ist jeder ganztägige Termin bei mir einen Tag zu lang. Und ein Datum, das auf Z endet, ist UTC und muss umgerechnet werden — der Rest ist Ortszeit. Fürs Lesen aus dem Fließtext deckst du beide deutschen Schreibweisen ab: 25.06.2026 und „25. Juni 2026“, jeweils mit und ohne Uhrzeit, und die Uhrzeit sowohl als 14:30 als auch als „14 Uhr“. Findest du nur ein Datum und keine Uhrzeit, leg einen ganztägigen Termin an, statt eine Uhrzeit zu erfinden. Findest du gar kein Datum, schreib das ins Protokoll und leg nichts an. Setz die Zeitzone in der Projektkonfiguration auf meine. Fehlt sie, rechnet das Skript in einer fremden Zone und alle Termine sitzen um Stunden daneben. Sortier die Regeln so, dass die erste Übereinstimmung gewinnt, und schreib mir dazu, in welcher Reihenfolge sie geprüft werden. Bei überlappenden Regeln entscheidet die Reihenfolge, und das soll ich sehen können, ohne den Code zu lesen. Protokollier jeden angelegten Termin mit Kalender und Titel, und jeden Fehlschlag mit dem Grund. Wenn du fertig bist, gib mir: ## Das Skript ## Wie ich es einrichte Schritt für Schritt: Projekt anlegen, Code einfügen, Zeitzone setzen, Trockenlauf starten, Berechtigungen erteilen, Auslöser einrichten. ## Wie ich die Termine in meiner Kalender-App sehe Google-Konto einbinden, Kalender einblenden, zum Standardkalender machen — für die App, die ich dir genannt habe. ## Was ich vor dem ersten echten Lauf prüfe ## Woran es scheitern wird Und zum Schluss: Sag mir in drei Sätzen, welche meiner Regeln du für zu weit gefasst hältst und welche Mails damit versehentlich im Kalender landen könnten.