This is not a re-ask of “please add recurring tasks”. That question is answered: Feature Request: Recurring Tasks got “We do have plans to add native support, but not this year most likely” (Jul 2025), and Recurring Tasks got “we will do it eventually” (Feb 2026).
I want to specify two things none of those threads cover, because our use case isolates them cleanly.
The use case
We have just committed to an event on a fixed forever pattern: the second Friday in October, every year.
Google Calendar took one line:
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=2FR
In Fibery we could not represent it at all, so we created the rows by hand.
1. Nth weekday of month is a different rule class
Every recurrence discussion here works in daily, weekly and monthly intervals, and every community workaround implements them as date arithmetic. “Second Friday in October” is not expressible that way. Across consecutive years it falls on the 8th, 13th, 12th, 11th and 10th. It is not “add N days” or “add N months” from anything.
Scheduled rules do not reach it either. The time-based trigger takes a unit of minute, hour, day, week or month, plus daysOfMonth of 1 to 28. There is no year unit and no nth-weekday selector, so the one native automation route cannot express the rule at all.
This is not an exotic case. It is how most fixed organisational dates are actually defined: first Monday of the month, last Friday of the quarter, second Tuesday for a board meeting.
2. A bounded set of occurrences, created up front
@Chr1sG has raised two fair objections to native recurrence (here): an Outlook-style indefinite recurrence cannot map to an infinite number of entities, and with no array field type a single entity cannot hold a set of recurrence dates.
Both objections dissolve if recurrence is bounded. We are not asking for infinity, and not for one entity holding many dates. We want: given a rule and a horizon, create that many ordinary entities now. Ten rows. Real entities, each independently editable, each appearing in every view, with no special occurrence semantics anywhere.
That also answers the question @RonMakesSystems asked in that thread and nobody replied to: generate up front, not on completion. On-completion generation only makes sense for tasks. A date in 2031 is not waiting for anyone to tick anything off.
The smallest version that would help
A generator, not a property on an entity. Feed it a recurrence rule and an end date, get entities. It does not need to track them afterwards, it does not need “edit this occurrence versus all future ones”, and it does not need to know or care whether the entity is a task. Even shipped as a button action on a database, this would have solved our case completely.
If that is still too much, the single highest-value increment is nth-weekday support in the existing scheduled rule trigger, which at least makes the rule expressible.