# đź“… New Calendar Feature: End Date for Recurring Events
**URL:** https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527
**Category:** Announcements
**Tags:** events
**Created:** [June 2, 2025, 11:42am UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527 "2025-06-02T11:42:29Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)
#### Post date: [June 2, 2025, 11:42am UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/1 "2025-06-02T11:42:29Z")
You can now set an end date for recurring events in Discourse Calendar! ✨
This much-requested feature allows you to specify when a recurring event series should stop, giving you more control over your event scheduling.
Create events that repeat daily, weekly, or monthly - and now determine exactly when they should end.
For more details on the Calendar plugin and its features, visit the [official Calendar topic](https://meta.discourse.org/t/discourse-calendar-and-event/97376).
In the future, we might add the possibility to exclude specific weekdays.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [June 3, 2025, 2:27am UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/2 "2025-06-03T02:27:08Z")
A tricky thing with the work “Until” is that it is not totally obvious if it is included or excluded? Is there anything we can do here to give better clarity?
---
### Author:  [@nathank](https://meta.discourse.org/u/nathank)
#### Post date: [June 3, 2025, 2:31am UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/3 "2025-06-03T02:31:59Z")
Yeah, Google Calendar has the same issue! They use `On`, but it suffers from the same ambiguity:
However, I think that most users would safely assume that `Until` includes that date.
---
### Author:  [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)
#### Post date: [June 3, 2025, 7:25am UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/4 "2025-06-03T07:25:38Z")
`Until (included):`
?
edit: I did this for now [UX: better copy by jjaffeux · Pull Request #737 · discourse/discourse-calendar · GitHub](https://github.com/discourse/discourse-calendar/pull/737) seems like a good simple change.
* * *
An alternative solution would be to display the actual date/time next to the date input, but probably overkill?
---
### Author:  [@meglio](https://meta.discourse.org/u/meglio)
#### Post date: [June 4, 2025, 3:03am UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/5 "2025-06-04T03:03:39Z")
> [@sam](#):
>
> A tricky thing with the work “Until” is that it is not totally obvious if it is included or excluded? Is there anything we can do here to give better clarity?
You might want to borrow some ideas from my impementation of the Voucher Start/End dates in the New Voucher dialog in an e-commerce I’m working on:
* * *
Another example to demonstrate the flexibility and how we avoid ambiguity in date ranges in the UI:
* * *
**Technical detail:** In our application, we always save dates as “timestamp with timezone” (postgres), so no database setting, nor connection setting, can affect the actual timestamp stored. Even though Postgres does not recommend it, we do it because it gives 100% guarantees of the date correctness in any situation and in any SQL query. You can operate with date timezones right in postgres using their date/time/timezone functions and be certain that it will work 100% correct always. We rely on it.
And then we have a timezone setting for all types of entities that need it: user profiles, markets, vouchers, reporting for accountants, and so on - so that we can translate any dates to any timezones on the fly without hesitation.
The main takeaways here are:
1. Always store date and time with timezone.
2. Always store timezone preference.
3. Be very explicit about dates in the UI, don’t do any magic.
4. Let the user see the actual dates in the choosen timezone before they click “Save”.
---
### Author:  [@MiniForum](https://meta.discourse.org/u/MiniForum)
#### Post date: [September 4, 2026, 8:13pm UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/6 "2026-09-04T20:13:23Z")
Hello,
On my self-hosted instance (just generated a month ago), I do not see any end date option.
Am I doing something wrong ?
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [September 4, 2026, 8:23pm UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/7 "2026-09-04T20:23:50Z")
I think the screenshot shows the **Insert date / time** dialog rather than the **Create event** dialog.
Those are two different workflows in Discourse Calendar:
- `Insert date / time` is used for replies in a topic whose OP contains a `[calendar]` block.
- `Create event` creates an actual Event (`[event ...][/event]`) and is where the recurring Event settings, including the recurrence end date, are available.
So for the feature announced in this topic, try opening the composer `+` menu and choosing **Create event** , rather than **Insert date / time**.
I was testing that recurring Event flow recently and also found an edge case after a bounded recurrence has completely expired, which I’ve opened a fix for here:
>
>
> \## Summary
>
> Fixes recurring Event labels rendering \`Every Invalid date\` after a …bounded recurrence has expired.
>
> When the final occurrence of a recurring Event has passed, \`starts\_at\` can be \`nil\` while the Event still retains its recurrence and serialized RRULE. The recurrence label was deriving its weekday from the missing \`starts\_at\`, resulting in an invalid Moment date.
>
> This change falls back to the original \`DTSTART\` contained in the serialized RRULE when there is no current \`startsAt\`.
>
> Existing behavior is unchanged while a current occurrence is available.
>
> \## Tests
>
> Added coverage for:
>
> \- an expired all-day weekly Event with no current occurrence
> \- an expired timed monthly Event using the fourth weekday of the month
>
> Manual smoke testing also covered:
>
> \- the original all-day weekly reproduction
> \- a timed weekly Event in \`Europe/London\`
> \- a timed fourth-Thursday monthly Event
>
> The broader discourse-events JavaScript run completed with:
>
> \> 274 tests, 273 passed, 1 skipped, 0 failed
>
> The focused expired-event tests pass with no deprecation warnings.
>
> Also verified with Prettier, ESLint, and \`git diff --check\`.
---
### Author:  [@MiniForum](https://meta.discourse.org/u/MiniForum)
#### Post date: [September 4, 2026, 8:41pm UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/8 "2026-09-04T20:41:37Z")
Indeed it was to maintain a calendar (collecting events) in a topic.
Sorry for the misunderstanding, I’m new to this.
Indeed when creating an event, it seems to work.
A pity that it does not work for `Insert date / time`.
Thanks for your help !
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [September 4, 2026, 8:48pm UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/9 "2026-09-04T20:48:15Z")
No problem 🙂
Just to clarify, I don’t think this is really a case of the feature not working for **Insert date / time** - it is a different workflow.
`Insert date / time` is used when you have a `[calendar]` block in the opening post of a topic and want dated replies to appear on that particular topic’s calendar.
**Create event** , on the other hand, creates an actual Discourse Event (`[event ...][/event]`). The recurring-event end date discussed in this topic applies to that Event recurrence system.
So if your aim is to maintain a calendar local to one topic, the workflow shown in your original screenshot is the appropriate one; it just doesn’t use the same bounded-recurrence feature as Events.
---
### Author:  [@MiniForum](https://meta.discourse.org/u/MiniForum)
#### Post date: [September 4, 2026, 9:06pm UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/10 "2026-09-04T21:06:29Z")
Yes I understand.
The use case is to maintain a calendar for my school. There are always appointments to be entered and so any parent can reply to the topic to add a new appointment.
But just yesterday, I needed to enter a recurring appointment and unfortunately we don’t have this option in this workflow. So I have to do it manually by replying many times to the topic with a new date (don’t know if there is a clever way…).
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [September 4, 2026, 9:19pm UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/11 "2026-09-04T21:19:28Z")
There may be a way to automate the manual replies while keeping your existing topic-local `[calendar]` workflow.
One possibility would be to use a dedicated Discourse user with reply-by-email enabled, then have something such as **Power Automate** or an **Azure Logic App** generate the individual dated replies and send them into the calendar topic by email.
For example, a weekly appointment with an end date could be expanded by the automation into the required individual replies, so parents would still see one normal topic calendar rather than separate Event topics.
There are a few details around Discourse’s per-user reply-by-email keys that would need to be set up carefully, so this topic probably isn’t the best place to go through the configuration.
If that approach would be useful to you, I’m happy to help work through it in a separate Meta topic.
---
### Author:  [@MiniForum](https://meta.discourse.org/u/MiniForum)
#### Post date: [September 4, 2026, 9:35pm UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/12 "2026-09-04T21:35:50Z")
It only happened once at the moment, so I’ll wait until next time (and hope that it won’t happen again).
I’ll keep the reply-by-email trick, thanks. But does that mean that for an event every week for a whole year, we’ll have to generate 52 replies ? It will make the topic difficult to read…
Otherwise I suppose, as I have admin rights, that I can also use the API to add manually the appointments.
Thanks for the insights !
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [September 4, 2026, 9:40pm UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/13 "2026-09-04T21:40:18Z")
Yes - unfortunately the API would automate creating the replies, but it wouldn’t really solve the clutter problem: for a topic calendar the individual calendar entries are still represented by individual replies.
I’ve just found an existing feature request which is almost exactly your use case:
> [@Add recurrent items within a date-range](https://meta.discourse.org/t/add-recurrent-items-within-a-date-range/286514):
>
> Using the [discourse-calendar-and-event](https://meta.discourse.org/t/discourse-calendar-and-event/97376), my fellow students and I were missing a feature that we think would improve the benefit of this plugin greatly. Imagine this case: We are using a calendar topic in order to organize the usage and occupancy of a specific room. For twelve consecutive Wednesdays, the room will be occupied by a course from 10 AM till 3 PM, except for one Wednesday. As of now we see two options to add recurring items that have a start -and end-date: We either post each dat…
Their example is a course occurring on twelve consecutive Wednesdays, and they make the same point: creating every occurrence individually is tedious and clutters the topic.
They suggest allowing recurrence in **Insert date / time** together with an end date for the final occurrence, which sounds very close to what you need.
So rather than building an API/Power Automate workaround that generates 52 posts, that feature request is probably the better place to add your school-calendar use case.
---
### Author:  [@MiniForum](https://meta.discourse.org/u/MiniForum)
#### Post date: [September 4, 2026, 9:54pm UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/14 "2026-09-04T21:54:36Z")
Thanks, I’ll do that !
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [September 5, 2026, 6:39am UTC](https://meta.discourse.org/t/new-calendar-feature-end-date-for-recurring-events/368527/15 "2026-09-05T06:39:24Z")
If you’re worried about clutter, i would recommend the `Events_calendar_categories` setting, rather than the per-topic calendar, and the parents’ can access Discourse by automation that leads to
> [@Creating a link to start a new topic with pre-filled information](https://meta.discourse.org/t/creating-a-link-to-start-a-new-topic-with-pre-filled-information/28074):
>
> bookmark This documentation explains how to create a link that starts a new topic in Discourse with pre-filled information. person_raising_hand Required user level: All users Sometimes you may want to provide users with a link that opens a new topic composer with certain information pre-filled. This can be useful for various use cases including bug report templates, feature requests, or standardized posts. Constructing the URL Base URL To compose a new pre-filled topic with no extra i…