Advanced date override handling and timezone compatibility improvements#6
Advanced date override handling and timezone compatibility improvements#6ShashankFC wants to merge 1 commit into
Conversation
* fix date override for fixed round robin + time zone in date override * check if slot is within working hours of fixed hosts * add test for date override in different time zone * fix date overrides for not fixed hosts (round robin) * code clean up * fix added test * use the correct timezone of user for date overrides --------- Co-authored-by: CarinaWolli <wollencarina@gmail.com>
|
bugbot run |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 4 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| workingHours.find((workingHour) => { | ||
| if (workingHour.days.includes(slotStartTime.day())) { | ||
| const start = slotStartTime.hour() * 60 + slotStartTime.minute(); | ||
| const end = slotStartTime.hour() * 60 + slotStartTime.minute(); |
There was a problem hiding this comment.
Working hours end time check uses wrong variable
High Severity
The end variable is computed from slotStartTime instead of slotEndTime, making it identical to start. This means the check end > workingHour.endTime is effectively start > workingHour.endTime, so slots whose end time extends past working hours will not be filtered out. Any slot whose start is within working hours will pass validation regardless of whether it actually fits.
| slotStartTime.format("YYYY MM DD") | ||
| ) { | ||
| dateOverrideExist = true; | ||
| if (dayjs(date.start).add(utcOffset, "minutes") === dayjs(date.end).add(utcOffset, "minutes")) { |
There was a problem hiding this comment.
Dayjs object reference comparison always returns false
High Severity
Two distinct dayjs objects are compared using ===, which checks reference equality and always evaluates to false. This means zero-duration date overrides (where start equals end, indicating the day is blocked off) are never detected. The comparison needs to use dayjs's .isSame() method instead.
| ) { | ||
| // slot is not within the date override | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Date override find logic rejects valid multi-override slots
High Severity
The dateOverrides.find() call returns the first override where the slot falls outside that override's time range. With multiple non-contiguous overrides on the same day (e.g., 9 AM–12 PM and 2 PM–5 PM), a slot at 10 AM is inside the first override but outside the second. find returns the second override (slot is outside it), causing the function to return false — incorrectly marking the slot as unavailable. The logic needs to verify the slot is outside all same-day overrides before rejecting it, not just any single one.
| ) { | ||
| // slot is outside of working hours | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Working hours find rejects valid slots with split schedules
High Severity
The workingHours.find() check has the same structural flaw as the date override logic. It rejects a slot if it falls outside ANY single working hours entry for the day, even if the slot is within a different entry. For users with split schedules (e.g., 9 AM–12 PM and 2 PM–5 PM), a slot at 10 AM is correctly within the first range but outside the second — find returns the second entry and the slot is incorrectly marked as unavailable.


Test 7nn
Summary by CodeRabbit
New Features
Tests
✏️ Tip: You can customize this high-level summary in your review settings.
nn---n*Replicated from [ai-code-review-evaluation/cal.com-coderabbit#7](https://github.com/ai-code-review-evaluation/cal.com-coderabbit/pull/7)*Note
Medium Risk
Touches core availability/slot filtering logic and introduces new timezone offset calculations, which could change bookable times in edge cases (DST, cross-midnight overrides, multi-host events). Test coverage is added but only for a narrow override scenario.
Overview
Improves date override handling so overrides are timezone-aware: overrides now carry the organizer/user
timeZonethroughgetSchedule, andgetTimeSlotsadjusts override start/end minutes by the invitee vs organizer UTC offset before computing slots.Tightens
getSchedulefiltering by expandingcheckIfIsAvailableto (1) accept a per-userorganizerTimeZone, (2) treat slots as available only if they fall within the active date override window when one exists for that day, and otherwise (3) reject slots outside normalworkingHours.Adds a Jest regression test ensuring a date override produces the same UTC slot times even when the invitee requests availability in a different timezone, and updates
TimeRangeto include optionaltimeZone.Written by Cursor Bugbot for commit 3ef3284. Configure here.