Ich muss ein Skript zum Veröffentlichen von .ICS-Dateien schreiben. Ich habe gelesen, dass es schwierig ist, dies richtig zu machen, entweder weil einige Kalender-Clients fehlerhaft sind (viele Leute behaupten, dass Google Kalender extrem buggy ist, insbesondere in Bezug auf Zeitzonen) oder weil Entwickler die Spezifikation nicht korrekt befolgen. Ich muss dies nur für Nordamerika tun, aber ich muss DST berücksichtigen (unter Berücksichtigung von Orten wie Arizona, von denen Teile die Sommerzeit beobachten und Teile davon nicht).
Kann jemand diese Fragen beantworten?
Irgendwelche anderen Tipps?
Sie haben richtig gehört - es ist nicht einfach. Einfach zu bieten sehr grundlegende ics-Unterstützung, nicht so einfach, vollständige Unterstützung zu bieten, was ein ics-Anbieter ausgeben kann; vor allem bei Wiederholungen, Ausnahmen, Änderungen und ja Zeitzonen.
Ich habe lange an meinem ics-Verlag gearbeitet, jetzt ist es ziemlich stabil. Ich habe unterwegs Notizen gemacht.
Siehe Ссылка . Auch das Zeitzonen-Tag auf meiner Seite mag hilfreich sein.
Insbesondere, wenn Sie in wiederkehrende Ereignisse geraten, ist der "ical cheatsheet" einen Blick wert. Ich habe meine Wiederholungsmaschine neu geschrieben, nachdem ich das durchgearbeitet hatte.
Google Ich habe nicht gefunden, um ein Problem zu sein, es ist die kleineren Spieler, besonders wenn sie beginnen, etwas nicht-Standard-Dinge (Zimbra / Pc basierte tz's usw.) zu tun.
Obwohl Google langsam aktualisieren kann (dh jemand aktualisiert seinen Google-Kalender, holen Sie die ics-Datei (definitiv nicht aus Ihrem Cache) und es hat das Update nicht - kann eine Stunde dauern oder so. Das war nicht gut für unsere Schule, wenn sie ihren Newsletter machen - sie machen auch einen Druck von der Webseite. SO habe ich jetzt die andere Seite erstellt - unseren eigenen ics Editor in wp.
Es gibt verschiedene kostenlose ical-Skripte da draußen - warum rollen Sie Ihre eigenen? Lust auf eine Herausforderung?
Zeiten in ICS-Dateien können entweder unverankert oder fest sein.
Ein floating datetime enthält keinen Verweis auf UTC oder eine Zeitzone - die Zeit sollte die Zeit sein, zu der der ATTENDEE für das Meeting in seiner lokalen Zeitzone ankommen sollte. Dies kann dazu führen, dass unterschiedliche Teilnehmer die Besprechung zu unterschiedlichen Zeiten abhalten, daher sollten sie mit Vorsicht (oder nie!) Verwendet werden.
Eine feste Zeit ist ein besserer Weg. Das Format ändert sich abhängig davon, ob das Meeting in UTC stattfindet oder nicht.
Für UTC-Meetings verwenden Sie Z , um UTC anzugeben:
Wenn das Meeting nicht in UTC angegeben ist, geben Sie mit dem TZID-Format eine Zeitzone an. Das Folgende repräsentiert 2 Uhr New Yorker Zeit:
%Vor%Hinweis: Das TZID-Format sollte nicht für UTC-Zeiten verwendet werden.
All dies ist in RFC 5545, Abschnitte 3.2.19 und 3.3.4
Der RFC hat Folgendes über DST zu sagen - lesen Sie es ein, was Sie wollen!
Wenn, basierend auf der Definition der Referenzzeitzone, die lokale Zeit beschrieben tritt mehr als einmal auf (wenn Wechsel von Tageslicht zu Standard Zeit) bezieht sich der Wert von DATE-TIME auf das erste Vorkommen des referenzierten Zeit. Also, TZID = Amerika / New_York: 20071104T013000 zeigt an 4. November 2007 um 1:30 Uhr Sommerzeit (UTC-04: 00). Wenn die lokale Zeit beschrieben tritt nicht auf (wenn Wechsel von Standard zu Tageslicht Zeit), ist der DATE-TIME-Wert interpretiert mit dem UTC-Offset vor der Lücke in lokalen Zeiten. So, TZID = Amerika / New_York: 20070311T023000 weist auf den 11. März 2007 um 3:30 Uhr nachmittags hin. EDT (UTC-04: 00), eine Stunde nach 1:30 A.M. EST (UTC-05: 00).