📅 New Calendar Feature: End Date for Recurring Events

[joffreyjaffeux]

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.

In the future, we might add the possibility to exclude specific weekdays.

[sam (Sam Saffron)]

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?

[nathank (Nathan Kershaw)]

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.

[joffreyjaffeux]

Until (included):

?

edit: I did this for now UX: better copy by jjaffeux · Pull Request #737 · discourse/discourse-calendar · GitHub 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?

[meglio (Anton)]

@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”.