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

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

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

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

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

Что я пока читаю по этому поводу:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

п. https://github.com/tplaner/When Это выглядит ОТЛИЧНО для создания дат на основе правил, включая RRULE's