Recurrence Rules End Date does not include event occuring on the end date

[tiarastore]

Background

The recurrence rules function in the events form allows user to set the end date of a recurring event series. Bedework is set to consider the series to end on 11:59 p.m. of the date prior to the end date. While logic would suggest an "end date" not include events on the ending date, and technical conventions may require this, my users do not interpret it thus.

Example: 1st Thursday Book Club occurs on first thursday of months of March April May, 2023. User sets begin date to Thursday, March 2; end date to Thursday, May 4.

every month(s) on the first Thurepeating until 2023-05-04

Expected

Based on repairing this error for users, I observe most users expect the end date to include events occuring on the end date (May 4). This convention is consistent with their company's enterprise calendar recurrence setting which includes events scheduled on the end date.

Proposed Fix

At least on the Add Event forms, when user selects an end date to a series, events that fall on this day should be included in the series.

[douglm]

Is this a new problem or prexisting? We use ical4j (a java library) to handle all recurrences and the standards make some statements which are in some cases ambiguous. It could be a ui issue in that we may end up with a date/time which is before the last date. Also having the end-date selection be essentially a search of the occurrences would also help. If it is a preexisting issue I'd prefer to implement a good solution - with your input - rather than a quick fix.

…

On 11/4/22 11:18, Kyle Cook wrote: Background The recurrence rules function in the events form allows user to set the end date of a recurring event series. Bedework is set to consider the series to end on 11:59 p.m. of the date prior to the end date. While logic would suggest an "end date" not include events on the ending date, and technical conventions may require this, my users do not interpret it thus. Example: 1st Thursday Book Club occurs on first thursday of months of March April May, 2023. User sets begin date to Thursday, March 2; end date to Thursday, May 4. |every month(s) on the first Thurepeating until 2023-05-04| Expected Based on repairing this error for users, I observe most users expect the end date to include events occuring on the end date (May 4). This convention is consistent with their company's enterprise calendar recurrence setting which includes events scheduled on the end date. Proposed Fix At least on the Add Event forms, when user selects an end date to a series, events that fall on this day should be included in the series. — Reply to this email directly, view it on GitHub <#156>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW2MBRMKG5ARADROVZNUVTWGUSK3ANCNFSM6AAAAAARXJCWWM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[spartanicus]

Kyle - I understand how this may be misunderstood by the user: they want to set the "last day" an event occurs and don't really understand "last-day + 1", right? I've also experienced end-user confusion about this for all-day events that don't recur. Mike - this is a UI issue, and probably one that could be configurable in the admin client (so that existing deployments that are accustomed to the original behavior can remain as they are or opt in). The back-end storage could remain exactly as it is - but if the admin client is set to use the behavior where end-date is inclusive, the end date saved by an event edit form would be converted to "end-date +1" prior to storage and then "end-date -1" when it's retrieved for editing back in the form. I expect this would only be used for end date settings for recurring or all-day events. The calendar front-end, downstream clients, and all else would behave as they always have. Arlen

…

On 11/4/22 1:36 PM, Mike Douglass wrote: Is this a new problem or prexisting? We use ical4j (a java library) to handle all recurrences and the standards make some statements which are in some cases ambiguous. It could be a ui issue in that we may end up with a date/time which is before the last date. Also having the end-date selection be essentially a search of the occurrences would also help. If it is a preexisting issue I'd prefer to implement a good solution - with your input - rather than a quick fix. On 11/4/22 11:18, Kyle Cook wrote: > > > Background > > The recurrence rules function in the events form allows user to set > the end date of a recurring event series. Bedework is set to consider > the series to end on 11:59 p.m. of the date prior to the end date. > While logic would suggest an "end date" not include events on the > ending date, and technical conventions may require this, my users do > not interpret it thus. > > Example: 1st Thursday Book Club occurs on first thursday of months of > March April May, 2023. User sets begin date to Thursday, March 2; end > date to Thursday, May 4. > > |every month(s) on the first Thurepeating until 2023-05-04| > > > Expected > > Based on repairing this error for users, I observe most users expect > the end date to include events occuring on the end date (May 4). This > convention is consistent with their company's enterprise calendar > recurrence setting which includes events scheduled on the end date. > > > Proposed Fix > > At least on the Add Event forms, when user selects an end date to a > series, events that fall on this day should be included in the series. > > — > Reply to this email directly, view it on GitHub > <#156>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAW2MBRMKG5ARADROVZNUVTWGUSK3ANCNFSM6AAAAAARXJCWWM>. > You are receiving this because you are subscribed to this > thread.Message ID: ***@***.***> > — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUE7Y7DT63HG7QOQ3XF2ULWGVCRDANCNFSM6AAAAAARXJCWWM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[douglm]

I'd missed the date-only issue - yes for date only it's routine for a UI to set the end date to date+1 the user sets. What I'd been considering is to just present the occurrences to the user as a list once they type the year adn narrow it down as they type - it would work for date-time occurrences as well and probably minimizes input errors. For now the major issue is whether or not this is a pre-existing issue - if pre-existing it should probably wait till after we get the system upgrade at Nashville in place - also I just realized this came in on the bedework issues - not the nashville issues so that probably answers the question.

…

On 11/4/22 13:51, Arlen Johnson wrote: Kyle - I understand how this may be misunderstood by the user: they want to set the "last day" an event occurs and don't really understand "last-day + 1", right? I've also experienced end-user confusion about this for all-day events that don't recur. Mike - this is a UI issue, and probably one that could be configurable in the admin client (so that existing deployments that are accustomed to the original behavior can remain as they are or opt in). The back-end storage could remain exactly as it is - but if the admin client is set to use the behavior where end-date is inclusive, the end date saved by an event edit form would be converted to "end-date +1" prior to storage and then "end-date -1" when it's retrieved for editing back in the form. I expect this would only be used for end date settings for recurring or all-day events. The calendar front-end, downstream clients, and all else would behave as they always have. Arlen On 11/4/22 1:36 PM, Mike Douglass wrote: > Is this a new problem or prexisting? > > We use ical4j (a java library) to handle all recurrences and the > standards make some statements which are in some cases ambiguous. > > It could be a ui issue in that we may end up with a date/time which is > before the last date. Also having the end-date selection be essentially > a search of the occurrences would also help. > > If it is a preexisting issue I'd prefer to implement a good solution - > with your input - rather than a quick fix. > > On 11/4/22 11:18, Kyle Cook wrote: > > > > > > Background > > > > The recurrence rules function in the events form allows user to set > > the end date of a recurring event series. Bedework is set to consider > > the series to end on 11:59 p.m. of the date prior to the end date. > > While logic would suggest an "end date" not include events on the > > ending date, and technical conventions may require this, my users do > > not interpret it thus. > > > > Example: 1st Thursday Book Club occurs on first thursday of months of > > March April May, 2023. User sets begin date to Thursday, March 2; end > > date to Thursday, May 4. > > > > |every month(s) on the first Thurepeating until 2023-05-04| > > > > > > Expected > > > > Based on repairing this error for users, I observe most users expect > > the end date to include events occuring on the end date (May 4). This > > convention is consistent with their company's enterprise calendar > > recurrence setting which includes events scheduled on the end date. > > > > > > Proposed Fix > > > > At least on the Add Event forms, when user selects an end date to a > > series, events that fall on this day should be included in the series. > > > > — > > Reply to this email directly, view it on GitHub > > <#156>, or unsubscribe > > > <https://github.com/notifications/unsubscribe-auth/AAW2MBRMKG5ARADROVZNUVTWGUSK3ANCNFSM6AAAAAARXJCWWM>. > > You are receiving this because you are subscribed to this > > thread.Message ID: ***@***.***> > > > > — > Reply to this email directly, view it on GitHub > <#156 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAUE7Y7DT63HG7QOQ3XF2ULWGVCRDANCNFSM6AAAAAARXJCWWM>. > You are receiving this because you are subscribed to this > thread.Message ID: ***@***.***> > — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW2MBTVY5FUKBRZBZ63HYTWGVEJJANCNFSM6AAAAAARXJCWWM>. You are receiving this because you commented.Message ID: ***@***.***>

[tiarastore]

This is a pre-existing issue present on current Nashville prod, and Nashville eventsdev. So, not specific to the present upgrade process.

This has been an issue for a long time (years). Not urgent to fix on project before deploying next version on Nashville. Should wait. Added to Bedework Issues instead.

I am noticing a trend that more users are having trouble interpreting that range-picker than in past years. Although I've always pointed it out while showing the interface in training. Of four users who added recurring events today, three made this entry error.

[douglm]

Another recurrence related issue - Yale asked that we suppress the no-end-date option as their major problem was users selecting that adn then they'd have to go back and fix it for them. By default that is on so the option has gone - I think it's still visible for admins. Do you want it left in that state for nashville?

…

On 11/4/22 15:09, Kyle Cook wrote: This is a pre-existing issue present on current Nashville prod, and Nashville eventsdev. So, not specific to the present upgrade process. This has been an issue for a long time (years). Not urgent to fix on project before deploying next version on Nashville. Should wait. Added to Bedework Issues instead. I am noticing a trend that more users are having trouble interpreting that range-picker than in past years. Although I've always pointed it out while showing the interface in training. Of four users who added recurring events today, three made this entry error. — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW2MBX7X2VXDEPNBL5SQEDWGVNQBANCNFSM6AAAAAARXJCWWM>. You are receiving this because you commented.Message ID: ***@***.***>

[tiarastore]

We also have problem with users leaving the default 'forever'. Is this option you refer to as no-end-date?

[douglm]

On 11/4/22 16:07, Kyle Cook wrote: We also have problem with users leaving the default 'forever'. Is this option you refer to as |no-end-date|?

That's the one

…

Screen Shot 2022-11-04 at 3 05 20 PM <https://user-images.githubusercontent.com/5504002/200065190-10946e05-3237-451b-a28e-f1b8133fb298.png> — Reply to this email directly, view it on GitHub <#156 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW2MBRYW7MUEMBLFCSYUXDWGVUHJANCNFSM6AAAAAARXJCWWM>. You are receiving this because you commented.Message ID: ***@***.***>

[tiarastore]

Affirmative to disabling this option for all users. We never want to have users able to select 'forever'

[tiarastore]

To original issue: I believe we were able to address this in the UI before--by adding a value of +1 somewhere in the settings. I can't locate this option now. However, our users are once again running into the problem while using the Repeat: until.

Users identify this repeat completion date as the last occurrence of the series, instead of the end of the logical date range during which the series repeats (the day after).

Our users' behavior replicates functionality of Outlook calendar's use of End Date, their UI describes this as Occurs every _Wednesday_ until