Skip to content

Advanced date override handling and timezone compatibility improvements#6

Open
ShashankFC wants to merge 1 commit into
date-algorithm-basefrom
date-algorithm-enhanced
Open

Advanced date override handling and timezone compatibility improvements#6
ShashankFC wants to merge 1 commit into
date-algorithm-basefrom
date-algorithm-enhanced

Conversation

@ShashankFC

@ShashankFC ShashankFC commented Jan 22, 2026

Copy link
Copy Markdown

Test 7nn

Summary by CodeRabbit

  • New Features

    • Improved timezone awareness for date overrides and availability calculations
    • Added working hours validation to availability checks
    • Enhanced date override processing to properly handle timezone offsets between organizers and invitees
  • Tests

    • Added test verifying timezone consistency across schedule calculations

✏️ 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 timeZone through getSchedule, and getTimeSlots adjusts override start/end minutes by the invitee vs organizer UTC offset before computing slots.

Tightens getSchedule filtering by expanding checkIfIsAvailable to (1) accept a per-user organizerTimeZone, (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 normal workingHours.

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 TimeRange to include optional timeZone.

Written by Cursor Bugbot for commit 3ef3284. Configure here.

* 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>
@ShashankFC

Copy link
Copy Markdown
Author

bugbot run

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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();

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Fix in Cursor Fix in Web

slotStartTime.format("YYYY MM DD")
) {
dateOverrideExist = true;
if (dayjs(date.start).add(utcOffset, "minutes") === dayjs(date.end).add(utcOffset, "minutes")) {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Fix in Cursor Fix in Web

) {
// slot is not within the date override
return false;
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Fix in Cursor Fix in Web

) {
// slot is outside of working hours
return false;
}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Fix in Cursor Fix in Web

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants