Расписание ИТМО жило в приложении, а мне нужен был календарь. Поэтому я сделал сервис

[stackshortlist]

Подписка через ссылку кажется самым правильным форматом, потому что календарь сам подтягивает переносы и не нужно ничего импортировать заново. Единственный нюанс, который встречал в похожих сервисах: некоторые календари обновляют подписки довольно редко, иногда раз в сутки, и срочный перенос пары может не успеть подтянуться. Как вы решаете эту проблему, или пользователям приходится мириться с задержкой?

[pod7686]

Спасибо, вопрос по делу. Тут задержка складывается из двух независимых вещей: как часто расписание забирает наш сервис и как часто ваш календарь опрашивает саму подписку.

На стороне сервиса: по умолчанию расписание обновляется раз в 3 часа, но в кабинете частоту можно поставить на 30 минут (это минимум). То есть данные у нас не старше получаса.

На стороне клиента: частоту опроса задаёт календарь. Мы отдаём подсказку REFRESH-INTERVAL на час, но клиент вправе её игнорировать. В Apple Календаре (macOS и iOS) можно открыть свойства подписки и выбрать автообновление вплоть до «каждые 5 минут» или вручную. Тогда перенос прилетает за считаные минуты.

Единственное место, где повлиять нельзя, это Google Календарь: внешние ICS-подписки он опрашивает по своему расписанию (обычно раз в несколько часов, иногда реже) и пользовательской настройки частоты там нет. Это ограничение платформы, а не сервиса.

Итого: если нужна максимальная оперативность, берите Apple Календарь (или CalDAV-клиент вроде DAVx⁵) и ставьте обновление раз в 5-15 минут, сервер при этом настроен на 30 минут. Худший случай тогда около получаса, обычно быстрее.

[hardcodd]

Интересно, как вы формируете UID события при переносе пары. Есть ли у занятия стабильный идентификатор в источнике, который сохраняется при смене времени и аудитории? Если нет, как отличаете перенос от удаления старой пары и появления новой? От этого зависит, увидит календарь обновление существующего события или отмену и новое событие.

[pod7686]

Честный ответ: стабильного идентификатора занятия в источнике нет - API отдаёт только поля (предмет, время, аудитория, преподаватель, группа).

Поэтому UID мы собираем из того, что обычно не меняется: студент, дата, время начала, предмет, группа. Аудитория, преподаватель, формат и тип в него намеренно не входят - их правка обновляет событие на месте. А перенос по времени (или смена предмета, группы) даёт новый UID: старую пару помечаем отменённой, появляется новая. Отмена держится пару дней, чтобы клиент её точно получил.

Склеивать перенос с прежней парой по эвристике не стали: надёжного признака «это та же пара, а не новая» в данных нет, а ошибка склейки хуже - она молча двигала бы чужое событие. Оговорка: смена предмета тоже даёт новый UID, хотя для человека это та же пара.