Написание файлов ICS для нескольких клиентов, включая Google - PullRequest
8 голосов
/ 21 сентября 2010

Мне нужно написать скрипт для публикации файлов .ICS. Я читал, что это трудно сделать правильно, потому что некоторые клиенты календаря глючат (многие люди утверждают, что Календарь Google очень глючит, особенно в отношении часовых поясов), или потому, что разработчики не следуют спецификации должным образом. Мне нужно сделать это только для Северной Америки, но я должен учитывать DST (имея в виду такие места, как Аризона, в некоторых местах наблюдается DST, а в некоторых нет).

Может кто-нибудь ответить на эти вопросы?

  1. При указании времени начала и окончания для события, если это будет предоставляется всегда в локальном пользователя время или я могу отправить его как время UTC и оставьте это клиенту, чтобы понять это из?
  2. Должен ли я взять какие-либо дополнительные шаги для учета ТЛЧ на местоположение пользователя?
  3. Должен ли я взять любые дополнительные шаги для учета Google

Есть еще советы?

Ответы [ 2 ]

8 голосов
/ 22 сентября 2010

Вы слышали правильно - это не легко. Легко предложить базовую поддержку ics, не так просто предложить полную поддержку того, что может выдать поставщик ics; особенно в отношении повторений, исключений, модификаций и да часовых поясов.

Я давно работаю над своим издателем ics, сейчас он довольно стабилен. Я сделал несколько заметок по пути.

См. http://icalevents.com/category/notes/. Также тег часового пояса на моем сайте может оказаться полезным.

В частности, если вы попадаете в повторяющиеся события, стоит посмотреть "ical cheatsheet". После этого я переписал свой рекуррентный движок.

Google Я не нашел проблемы, это мелкие игроки, особенно когда они начинают делать немного нестандартные вещи (tz's на основе Zimbra / Pc и т. Д.).

Хотя Google может медленно обновляться (то есть кто-то обновляет их календарь Google, вы повторно загружаете файл ics (определенно не из вашего кэша), и у него нет обновления - это может занять около часа. Это было бесполезно для наша школа, когда делает свою новостную рассылку - они тоже печатают с веб-сайта. Так что я сейчас прибегаю к созданию другой стороны - нашего собственного редактора ics в wp.

Существуют различные бесплатные скрипты - зачем катать свои? Стремитесь к вызову?

5 голосов
/ 21 сентября 2010

Время в файлах ICS может быть плавающим или фиксированным.

Плавающая дата и время не содержат ссылки на UTC или часовой пояс - это время должно быть временем, когда ПОТРЕБИТЕЛЬ должен прибыть на собрание в своем местном часовом поясе. Это может привести к тому, что разные участники будут проводить собрания в разное время, поэтому их следует использовать с осторожностью (или никогда!).

Фиксированное время - лучший путь. Формат меняется в зависимости от того, проходит ли встреча в формате UTC или нет.

Для собраний UTC, используйте Z, чтобы указать UTC:

19980119T070000Z

Если собрание не в формате UTC, используйте формат TZID, чтобы указать часовой пояс. Следующее представляет 2:00 по нью-йоркскому времени:

TZID=America/New_York:19980119T020000

Примечание: формат TZID не должен использоваться для времени UTC.

Все это указано в RFC 5545, разделах 3.2.19 и 3.3.4

RFC может сказать следующее о DST - прочитайте в нем, что вы будете!

Если, основываясь на определении часовой пояс, местное время описанное происходит более одного раза (когда переход от дневного света к стандартному время), значение ДАТА-ВРЕМЯ относится к первое вхождение упомянутой время. Таким образом, TZID = Америка / New_York: 20071104T013000 указывает 4 ноября 2007 года в 1:30 утра летнее североамериканское восточное время (UTC-04: 00). Если местное время описанный не происходит (когда меняется со стандартного на дневной время), значение ДАТА-ВРЕМЯ интерпретируется с использованием смещения UTC до разрыва в местном времени. Таким образом, TZID = Америка / Триатлон: 20070311T023000 указывает на 11 марта 2007 года в 3:30 утра EDT (UTC-04: 00), один час после 1:30 Член-корреспондент EST (UTC-05: 00).

...