Ну, в этом решении эта задача решается проматыванием полученной последовательности до начала этого отрезка и собиранием элементов до его окончания.
Да, проматывание этой последовательности с начала может быть небыстрым. Этого можно избежать, если для каждого правила сделать способ получения первого значения с датой не раньше заданной и собрать из таких общую последовательность на начале отрезка – и листать вперёд уже её. Звучит реализуемо, но зависит от требуемых правил.

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

Ну, собственно это оно и есть. Просто я зачем-то сразу делаю их выдачу в отсортированном виде с минимумом накопления в памяти :)

это самая, пожалуй, наивная имплементация, я и думал с неё начать

встал вопрос, что этих эвентов может быть слишком дохера, а потому нужна реализация LIMIT'a и OFFSET'a

а, ты просто эти функции/генераторы/итераторы оборачиваешь в один генератор который их выдает сразу в хронологии - тоже вариант
но есть ли в этом смысл? потому что клиенту может быть все равно на хронологию

а тогда встает вопрос о том, что разные генерирующие функции создают эвенты с разной частотой

если нужен limit в хронологическом смысле, то да. хронологический fan-in решает проблему. и offset тоже легко туда же прикручивается

"хронологический fan-in" – вот этот термин я искал

о, клёво

Это совершенно не страшно – последовательность ведь берёт ближайший ивент независимо от того, каким правилом он сгенерирован.

осталось решить как в базе хранить функции
первое что приходит в голову: в формате cron, вычитывать из базы и превращать в функции-генераторы в рантайме

но это тоже не тривиальная задача

а знаете че, я кажется придумал решение для оффсетов, надо опробовать

дам знать, если получится

хотя, есть вот такая оговорочка
Все условия (времени запуска) проверяются по «логическому И», кроме условий «день недели» и «день месяца» — указанные совместно, они обрабатываются по «логическому ИЛИ», то есть «по любому из дней», что отражено в документации (Ubuntu, Debian, FreeBSD). Однако такая логика неочевидна и не позволяет создать условие типа «первый понедельник каждого месяца» или «каждую пятницу в 13 число». Разработчики не изменяют данное поведение, считая его стандартом.

Крон вроде не предусматривает начало и конец правила, как это бывает с ивентами. Так что кроновские выражения, наверное, не лучший выбор.

Можно не мудрствовать и просто сделать название правила и набор его параметров, специфичный именно для этого вида правил. Формат совершенно неважен, хоть строка CSV – лишь бы валидация была нормальной.

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

периодический или нет - неважно