Advanced date override handling and timezone compatibility improvements #7
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 <[email protected]>
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Greptile Summary
This PR enhances timezone compatibility for date override functionality in the Cal.com scheduling system. The changes span across type definitions, slot calculation logic, and availability checking.
The core changes include:
-
Type System Enhancement: Added an optional
timeZonefield to theTimeRangetype inpackages/types/schedule.d.ts, enabling timezone context to be stored with date overrides. -
Slot Calculation Improvements: Modified
packages/lib/slots.tsto implement sophisticated timezone offset calculations when processing date overrides. The system now calculates the difference between organizer and invitee UTC offsets and adjusts override times accordingly. -
Availability Checking Logic: Enhanced
packages/trpc/server/routers/viewer/slots.tswith new parameters (dateOverrides,workingHours,organizerTimeZone) to thecheckIfIsAvailablefunction. This includes complex date override validation with timezone offset calculations and working hours validation as a fallback. -
Test Coverage: Added a comprehensive test case in
apps/web/test/lib/getSchedule.test.tsto verify that date overrides maintain UTC consistency when requested from different timezones.
These changes address the critical need for consistent timezone handling in a global scheduling application, ensuring that availability calculations remain accurate regardless of the timezone differences between organizers and invitees. The implementation focuses on maintaining UTC consistency while properly handling timezone-specific date overrides.
Confidence score: 1/5
• This PR has critical bugs that will cause immediate production issues and should not be merged.
• The timezone calculation logic contains fundamental errors, including incomplete implementations, mathematical mistakes in UTC offset calculations, and a critical bug in working hours validation that could break availability checking.
• All modified files need significant attention, particularly packages/lib/slots.ts and packages/trpc/server/routers/viewer/slots.ts which contain the most critical issues.
4 files reviewed, 1 comment
| 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.
logic: Bug: end should use slotEndTime instead of slotStartTime. This will incorrectly validate working hours as both start and end use the same time.
| const end = slotStartTime.hour() * 60 + slotStartTime.minute(); | |
| const end = slotEndTime.hour() * 60 + slotEndTime.minute(); |
| 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.
logic: Potential issue: Using === for dayjs comparison may not work as expected. Consider using .isSame() method instead.
| if (dayjs(date.start).add(utcOffset, "minutes") === dayjs(date.end).add(utcOffset, "minutes")) { | |
| if (dayjs(date.start).add(utcOffset, "minutes").isSame(dayjs(date.end).add(utcOffset, "minutes"))) { |
|
This PR is being marked as stale due to inactivity. |
2 participants
Test 7