Multi-day calendar Blocks: misleading “start time” on day two (labels vs duplicate bars)

Objective

• Make multi-day calendar Block events easy to interpret on the timeline so staff do not read “the second day starts at the same clock time as day one” when the intent is a single continuous PTO/block spanning overnight or across calendar dates.
• Resolve ambiguity between (A) misleading labels vs (B) duplicate geometry (two bars both aligned to morning time on successive days)—decision needed after verifying whether one or both occur in production.

Background

• Product mirrors ATT-1657 (timing shift) but as a separate observation: when one logical multi-day Block is created, day two can look like another block beginning at the same start time (e.g. 9 AM) as day one, instead of clearly reading as continuation of one span.
• Block bodies use CalendarEventBody with a times row that prints tzDayjs(event.datetime) and tzDayjs(event.endtime) only—no calendar dates in that snippet—so hovering or reading the pill on any horizontal segment shows the full original start and end clocks (e.g. “9:00 AM – 7:00 PM”) even when the bar visually crosses into the next calendar column. That can be misread as “this column’s block starts at 9 AM Tuesday and again at 9 AM Wednesday.”
• Designed placement model: useEventPlacement calls eventPlacementFuncMemoized(finalEventData, dates[0], …)—one timeline anchor per row; CalendarEventWrapper positions with left: event.startHours * gridWidth and width: lengthHours * gridWidth for a single DOM pill. So if geometry truly restarts at morning time on column two for the same _id, that would be inconsistent with placement intent and warrants a geometry/payload defect investigation.
• Separate from multi-date batch: AddEventModel multi-date mode creates one event per date with the same clock window each day—which is intentionally “9 AM-ish each day”; authors must not confuse that workflow with one spanning interval.

Scope

Frontend — display & labeling

• attik-frontend/src/components/calendar/CalendarEventBody.tsx — times segment for Block (and any shared body): today h:mmA – h:mmA without dates or per-visible-day context.
• attik-frontend/src/components/calendar/CalendarEventWrapper.tsx — Block body config (title, times); hover expansion behavior overlapping multi-day spans.
• attik-frontend/src/components/calendar/CalendarRow.tsx / CalendarEventWrapper — confirm overflow / clipping does not visually suggest a second bar when one continuous bar crosses column boundaries.

Frontend — placement (if geometry bug)

• attik-frontend/src/components/calendar/eventPlacementFunc.tsx — calcHours, findNumbers, eventPlacementFunc; week boundaries vs multi-day lengthHours.

Backend (only if duplicates confirmed)

• Event list / calendar aggregation endpoints — verify two distinct event documents (_id) are not returned for one user gesture (would explain two morning-aligned bars).

Product / architecture decisions (for the implementer)

• Decision needed: Improve copy only (e.g. include dates in times, or “Continues…” segment labels) vs segment multi-day renders.
• Decision needed: If duplicate rows exist, prioritize dedupe at source vs UI collapse.

Investigation outcomes (draft acceptance)

• [ ] For one repro: confirm single _id in network response vs two rows for same PTO intent.
• [ ] Screenshot wide vs compact hover on second column with times visible.
• [ ] Relate findings to ATT-1657 (timezone shift) if payloads share root cause.

References

• Related: ATT-1657 (cross-day Block date shift / timezone).
• Block body times: attik-frontend/src/components/calendar/CalendarEventBody.tsx
• Block wrapper config: attik-frontend/src/components/calendar/CalendarEventWrapper.tsx
• Placement pipeline: attik-frontend/src/components/calendar/useEventPlacement.ts, eventPlacementFunc.tsx
• Create paths: attik-frontend/src/app/tools/calendar/AddEventModel.tsx
• Event persistence: attik-backend/src/models/eventSchema.ts