Приглашения iCalendar: UID, SEQUENCE и правильные часовые пояса

Что это такое

iCalendar (RFC 5545, тип данных text/calendar) описывает события как компоненты VEVENT внутри VCALENDAR. iTIP (RFC 5546) определяет их обмен: METHOD:REQUEST от организатора, METHOD:REPLY от участников с PARTSTAT (принято, отклонено, предварительно), METHOD:CANCEL для отмены. Во всех сообщениях событие идентифицируется через UID, а его редакция — через SEQUENCE, который организатор обязан увеличивать при изменении DTSTART, DTEND, DURATION, RRULE и подобных свойств. Время имеет три формы: UTC (20260916T090000Z), местное время с параметром TZID, ссылающимся на компонент VTIMEZONE в том же объекте (DTSTART;TZID=Europe/Zurich:20260916T110000), и плавающее время без обоих признаков, означающее «11:00 там, где находится читатель». RFC 5545 требует VTIMEZONE для каждого используемого TZID и предупреждает, что его отсутствие приводит к непоследовательной интерпретации местного времени.

Почему это важно

Приглашение, которое после перехода на летнее время сдвигается на час или создаёт дубликат при каждом обновлении, хуже отсутствующего. Календари — одна из областей, где «хранить UTC» недостаточно: еженедельная встреча в Цюрихе в 09:00 должна оставаться в 09:00 местного времени при переходах в марте и октябре, а выразить это можно только местным временем с привязкой к часовому поясу.

Как применять

• Создайте для каждого события стабильный UID, сохраните его, используйте во всех обновлениях и отменах и увеличивайте SEQUENCE при каждом существенном изменении; DTSTAMP — время сообщения, а не счётчик редакций.
• Используйте TZID с именами поясов IANA и встраивайте корректный VTIMEZONE (с правилами STANDARD и DAYLIGHT) из поддерживаемой библиотеки. Для разовых событий с участниками из многих поясов используйте UTC, а плавающее время — только для того, что действительно следует местным часам читателя; события на весь день используют значение DATE (DTSTART;VALUE=DATE:20260916), а не плавающую полночь.
• Для повторяющихся событий следуйте RFC 5545: если у DTSTART есть TZID, часть UNTIL правила должна быть в UTC. Изменяйте отдельные вхождения через RECURRENCE-ID, а не редактированием всей серии.
• Отправляйте приглашения как часть text/calendar с заданным параметром method (method=REQUEST) и добавляйте тот же объект вложением .ics для клиентов, которые игнорируют этот параметр.
• Проверьте полный цикл обмена как минимум с двумя семействами клиентов на границе перехода летнего времени, включая обновление и отмену.

Подводные камни

Новый UID при каждом обновлении (дубликаты). Имена поясов, не являющиеся идентификаторами IANA, которые другие клиенты не могут сопоставить. Отмена с STATUS:CANCELLED, но без METHOD:CANCEL. События на весь день, отправленные от полуночи до полуночи UTC, из-за чего в других поясах они сдвигаются на день. Отправка CANCEL без увеличения SEQUENCE, которого требует RFC 5546.