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:
Always store date and time with timezone.
Always store timezone preference.
Be very explicit about dates in the UI, don’t do any magic.
Let the user see the actual dates in the choosen timezone before they click “Save”.
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:
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.
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…).
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.
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.
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:
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.
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