Closes #22764

Summary

For an all-day event, the base event correctly ignores the time of day, so its displayTimezone is flattened to the start and end of the day. Its recurring occurrences did not do the same. When an all-day event was authored with non-midnight times (for example 09:00 to 18:00), every generated occurrence kept that raw sub-day span instead of covering the whole day. This breaks the "all-day equals whole day" convention and makes the repeats inconsistent with the first instance.

This is an edge case: it only triggers when an all-day event carries non-midnight times. Events created through the picker are already midnight-aligned, so they never hit it.

Root cause

processEvent normalizes only the base event's displayTimezone to startOfDay and endOfDay for all-day events. It leaves dataTimezone with the raw authored times. When getRecurringEventOccurrencesForVisibleDays builds each occurrence in addOccurrence, it projects the occurrence start and end into the display timezone but does not re-apply that all-day flattening, so the raw sub-day span leaks into the occurrence's displayTimezone.

Fix

In addOccurrence, when the event is all-day, wrap the display-timezone start in startOfDay and the end in endOfDay. This mirrors exactly what processEvent already does for the base event, so each occurrence's displayTimezone becomes identical in shape to the base instance (00:00:00.000 to 23:59:59.999 [minutesInDay 0 to 1439]).

dataTimezone is deliberately left untouched, for two reasons:

1. It keeps parity with the base event, whose dataTimezone is also raw for all-day events.
2. The recurring edit, paste, and serialization paths read dataTimezone to write values back into the user's model. Normalizing it there (the alternative considered in the issue) would silently overwrite the authored times on those flows. Keeping the change to displayTimezone only avoids that risk, and rendering reads displayTimezone exclusively, so the visible bug is fully fixed.

getOccurrenceEnd is unchanged.

Steps to reproduce

Author an all-day recurring event with non-midnight times and expand it:

EventBuilder.new()
  .span('2025-01-10T09:00:00Z', '2025-01-10T18:00:00Z', { allDay: true })
  .rrule({ freq: 'DAILY', interval: 1 })
  .toProcessed();
// then getRecurringEventOccurrencesForVisibleDays(...)

Before this change, each occurrence reports displayTimezone.start.minutesInDay = 540 and end = 1080 (09:00 to 18:00). After, it reports 0 and 1439 (whole day), matching the base instance. In EventCalendarPremium and EventTimelinePremium, views that derive an event's duration from displayTimezone showed the repeats as 9-hour blocks instead of whole days; now they match the first instance.

Testing

Added two regression tests to getRecurringEventOccurrencesForVisibleDays.test.ts, covering a single-day and a multi-day all-day series authored with sub-day times. Both assert the occurrences span the whole day on each end. They fail on the current code (expected 540 to equal 0) and pass with the fix. Full package suite stays green (445 tests), typecheck, eslint, and prettier all pass.

Changelog

Fix all-day recurring occurrences keeping a raw sub-day duration instead of spanning the whole day in @mui/x-scheduler-internals-premium.

• I have followed (at least) the PR section of the contributing guide.