Заполнение повторений событий VS Запрос событий календаря на основе правил повторения

Я создаю спецификации для приложения PHP / mySQL Calendar для клиента. Одной из проблем, которые необходимо решить, являются повторяющиеся события, частота которых определяется правилами, такими как «ежегодно в первые выходные, для которых воскресенье — май». Клиент хотел бы иметь возможность устанавливать правила типа «происходит каждый третий четверг марта — июнь» и т. Д.

Клиент попросил, чтобы у них была возможность определить их, а не предварительно заполнять ими таблицу происшествий в течение следующих X лет.

Существуют ли какие-либо календарные решения, которые допускают такого рода повторения на основе шаблонов?

Есть ли в какой-либо системе календаря запрос, основанный на подобных правилах, а не на использовании параметров для генерации повторяющихся событий в таблице событий во время создания или обновления повторяющегося события?

Что я читаю по этому вопросу до сих пор:

а. http://martinfowler.com/apsupp/recurring.pdf

б. http://www.kanzaki.com/docs/ical/recur.html

с. http://tools.ietf.org/html/rfc5545#page-37

д. http://tools.ietf.org/html/rfc5545#section-3.8.5.3

е. ческих "поле" список (для схемы базы данных на основе стандарта iCal)

е. Каков наилучший способ моделирования повторяющихся событий в приложении календаря?

г. http://en.wikipedia.org/wiki/ICalendar#Technical%5Fspecifications

час http://muddybranch.thejkgroup.com/2005/01/why-remove-icalendar-recurring-rules/

я. Должен ли я хранить даты или правила повторения в моей базе данных при создании приложения календаря?

Примечание: этот предлагает хранить правила повторения, а также хранить жестко
случаи, основанные на них на х месяцев вперед.

к. Структура данных для хранения повторяющихся событий?

к. Должен ли я хранить даты или правила повторения в моей базе данных при создании приложения календаря?

я. Разделите ваши данные на две части: «канонические» данные (
правило повторения) и «обслуживание» (сгенерированные даты; только для чтения, кроме
регенерации). Если канонические данные изменяются, восстановите «обслуживающие» данные в этой точке. Для бесконечных повторений сохраните некоторое количество
экземпляры и генерировать больше, если у вас закончились (например, если пользователь смотрит на
их календарь на 2020 год).

л. Календарь повторяющихся / повторяющихся событий — лучший способ хранения Уникальный ответ со схемой и SQL

м. https://github.com/tusharmath/sheql Язык для повторяющихся дат

п. https://github.com/tplaner/When Это выглядит здорово для создания дат на основе правил — в том числе RRULE