test: add failing test case for recurring booking timezone bug #24666
+92
−3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This test demonstrates the timezone bug where recurring bookings are calculated incorrectly when the user's timezone (CET) differs from the execution environment timezone. The test shows that when a user in CET selects 10:00 AM for recurring meetings, the dates are generated at 11:00 AM instead, off by 1 hour. This is caused by timezone-naive date parsing in parseRecurringDates function where dayjs(startDate) parses without timezone context. Co-Authored-By: [email protected] <[email protected]>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
This fixes the recurring booking timezone bug where bookings were generated at incorrect times for users in different timezones (e.g., CET). The fix ensures that: 1. startDate is parsed in the user's selected timezone using dayjs.tz() 2. UTC offset calculations use the correct timezone context 3. DST transitions are handled correctly Changes: - Line 102: Use dayjs.tz(startDate, timeZone) instead of dayjs(startDate) - Line 105: Use dayjs.tz(startDate, timeZone) for offset calculation - Line 109: Use dayjs(t).tz(timeZone) for DST offset calculation Tests now pass, confirming recurring bookings are generated at the correct time in the user's timezone. Co-Authored-By: [email protected] <[email protected]>
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
E2E results are ready! |
eunjae-lee
reviewed
Oct 24, 2025
eunjae-lee
approved these changes
Oct 24, 2025
CarinaWolli
requested changes
Oct 24, 2025
There was a problem hiding this comment.
Saw this bug that I can't reproduce in main: https://www.loom.com/share/2bb22bc242164e6b9af79069919ab451
|
Closing this since it was a local timezone issue with Node.js using the system timezone by default. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
This PR adds failing test cases that demonstrate a timezone bug in recurring bookings for users in CET (Central European Time). The tests are intentionally failing to show the bug before the fix is applied.
Bug Description: When a user in CET selects a recurring meeting time (e.g., 10:00 AM), the system generates bookings at the wrong time (11:00 AM) due to timezone-naive date parsing in the
parseRecurringDatesfunction.Root Cause: The
parseRecurringDatesfunction inpackages/lib/parse-dates.tsusesdayjs(startDate)without timezone context, causing dates to be parsed in the execution environment's timezone rather than the user's selected timezone.Session Info:
Test Coverage
Two test cases are added:
Both tests currently fail, showing times at 11:00 instead of 10:00 (1-hour offset).
How should this be tested?
Run the tests with:
TZ=UTC yarn test packages/lib/parse-dates.test.tsExpected behavior: Tests should fail, demonstrating the bug
Next Steps
After CI confirms these tests fail as expected, a follow-up PR will apply the fix:
Mandatory Tasks
Checklist
Summary by cubic
Adds two failing tests that reproduce the recurring booking timezone bug for CET users, where a 10:00 selection is generated at 11:00. The cases expose timezone‑naive parsing in parseRecurringDates and cover both weekly recurrence and a DST transition.