Sierra widget all day exclusions inconsistencies

Not sure related to it or not, however, we noticed. During creating a new node if the Event date is in the past or the future (not today) and the "All day" checkbox is enabled, after a custom rule https://take.ms/OUYIc, when opening the "Occurrences" widget the dates start from today in popup https://take.ms/d9Iwrd. Will have a look more and provide a patch or will open another issue.

Please ignore my comment #5. I found better issue for it https://www.drupal.org/project/date_recur_modular/issues/3188671 🐛 Monthly mode works incorrect if use All day with empty time fields Needs work .

The patch in #4 fixes this with All Day events, but actually breaks exclusions for events that aren't all day. This is because when generating occurrences rrule compares the exact timestamp of exdates to the occurrence, so if the time doesn't match it's not excluded.

I think a better solution is to check for the All Day toggle in transferStateToTempstore and set the correct start/end time if it is on.

I actually think this should also fix the issue in 🐛 Monthly mode works incorrect if use All day with empty time fields Needs work

Rebase for 3.2.x

Shouldn't the granularity need to be seconds and not minutes (in the patch)

-      $form_state->setValue(\array_merge($valueParents, ['time_start']), '00:00:00');
-      $form_state->setValue(\array_merge($valueParents, ['time_end']), '23:59:59');
+      $form_state->setValue(\array_merge($valueParents, ['time_start']), '00:00');
+      $form_state->setValue(\array_merge($valueParents, ['time_end']), '23:59');

I would assume 23:59:59 would be the fix here?

This might be good to have a test case to cover this bug report?

So there are two different issues being solved by this patch, but the same lines of code are involved so it makes sense to fix them together.

The first issue is that if you create an all day recurring event with exclusions, the exclusions get stored with the original start/end times — which won't match the event times post save. Checking for the "all day" flag and normalizing the start/end times in transferStateToTempstore solves this.

The other issue is related to the seconds. Despite formElement() trying to set step to 1, the form element still ends up being rendered with step 60.

I'm not sure why that is, but it doesn't cause any problems except for all day events where the value is set with seconds by the validation. In Chrome, this doesn't affect anything (it just ignores the seconds), but in Safari it won't validate the input if the value is more granular than the step.

Figuring out why the step is 60 would be another way to solve this issue, but it doesn't seem necessary. Since all-day events aren't time based anyway, it makes no difference to have that extra granularity.