Make calendar-scale scheduling a first-class capability

[nielsrowinbik]

Problem statement

Native time triggers handle daily granularity only. Anything coarser (every other week, monthly, yearly), day-of-week-specific times, seasonal enablement, or before/after time windows on patterns requires calendar entities, template hacks, or duplicate automations. Common scheduling needs are therefore disproportionately hard to express, pushing users toward fragile workarounds for what feel like basic requirements.

Community signals

Moderate-to-strong standing demand, sustained across many independent requests over a long time span rather than a single spike.

• #801 Add every week, every other week, every month, every year to time trigger
• #800 Add weeks, months and years to time pattern trigger
• #26 Time trigger should support 'day' too (early request)
• #252 Trigger automation on manual date and time
• #2850 Time range before and after selected time in automation
• #4130 time_pattern trigger: add optional after / before time window (recent request)
• #3062 Add internal integration "Month"
• #2602 Winter / Summer automations
• #2784 New automation trigger for "Calendar Event Added"

The spread from an early request (#26) to a recent one (#4130) suggests a steady, unmet need rather than a passing trend.

Scope & Boundaries

In scope

• Recurrence coarser than daily: every week, every other week (interval-based), monthly, yearly
• Day-of-week-specific times
• Before/after time windows layered onto time patterns
• Seasonal or date-range enablement of triggers

Not in scope

• Full calendar event modelling (attendees, invites, RSVP handling)
• Reworking calendar entity integrations themselves
• The legacy time trigger's existing behaviour, which should remain backward compatible

Foreseen solution

Extend the new triggers and conditions system so scheduling beyond daily granularity is a native, first-class capability rather than a workaround. This means introducing recurrence and windowed scheduling as dedicated trigger and condition building blocks, with a clear division of responsibility against existing calendar entities so users know which tool to reach for.

Risks & open questions

• Where does the boundary sit between richer time triggers and existing calendar entities? Overlap risks user confusion about which tool to reach for.
• Recurrence semantics (interval anchoring, DST transitions, timezone handling, month-end edge cases) are notoriously error-prone and need careful specification.
• Should seasonal enablement be a first-class concept, or expressed through date-range conditions composed with existing triggers?

Appetite

To be set.

Execution issues

No response

Decision log

Date	Decision	Outcome