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?
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.