fix: apply recurring DST correction in the event timezone

[winklemad]

What does this PR do?

parseRecurringDates (packages/lib/parse-dates.ts) computes its per-occurrence DST correction from the runtime's local timezone rather than the event timeZone:

const startUtcOffset = dayjs(startDate).utcOffset();          // runtime-local offset
// ...
return dayjs.utc(t).add(startUtcOffset - dayjs(t).utcOffset(), "minute");  // runtime-local offset

The booker lets a user pick a meeting timezone independent of their browser timezone, so browser TZ ≠ meeting TZ is normal input. When they differ, every recurring occurrence after the event zone's DST transition drifts by an hour, and these instants are used as the actual booking start/end — parseRecurringDates's returned Date[] feeds mapRecurringBookingToMutationInput (packages/features/bookings/lib/client/booking-event-form/booking-to-mutation-input-mapper.tsx:107) and the occurrence list in Occurences.tsx. So this is wrong booking times, not just a display glitch.

Reproduced with a weekly 10:00 America/New_York booking crossing US spring-forward (2025-03-09), booker runtime Asia/Dubai (each instant shown as its New-York wall clock):

• before: 10:00, 11:00, 11:00, 11:00 ❌ (post-DST occurrences drift +1h)
• after: 10:00, 10:00, 10:00, 10:00 ✅

When the runtime timezone equals the event timezone the current code is already correct — confirming the intent is to hold the event-timezone wall-clock, so the cross-timezone drift is a genuine bug.

Fix: read both offsets in the event timeZone (.tz(timeZone).utcOffset()), matching the function's own comment ("UTC still need to have DST applied").

• No linked issue — found by reading the code.

Visual Demo (For contributors especially)

Non-visual (timezone/scheduling logic). The reproduction is the code + before/after above.

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• N/A — this fix does not require a developer-docs change.
• I confirm automated tests are in place that prove my fix is effective (packages/lib/parse-dates.timezone.test.ts).

How should this be tested?

packages/lib/parse-dates.timezone.test.ts (runs in the VITEST_MODE=timezone suite; sets process.env.TZ = "Asia/Dubai") asserts a weekly 10:00 America/New_York recurrence crossing the 2025-03-09 DST boundary keeps all four occurrences at 10:00. It fails on the current code (occurrences 2–4 become 11:00) and passes with the fix.

• No environment variables needed.
• No test data / DB needed — parseRecurringDates is a pure function.
• Expected: ["2025-03-05 10:00","2025-03-12 10:00","2025-03-19 10:00","2025-03-26 10:00"] (New-York wall clock), regardless of the runtime timezone.

[github-actions]

Welcome to Cal.diy, @winklemad! Thanks for opening this pull request.

A few things to keep in mind:

• This is Cal.diy, not Cal.com. Cal.diy is a community-driven, fully open-source fork of Cal.com licensed under MIT. Your changes here will be part of Cal.diy — they will not be deployed to the Cal.com production app.
• Please review our Contributing Guidelines if you haven't already.
• Make sure your PR title follows the Conventional Commits format.

A maintainer will review your PR soon. Thanks for contributing!

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 60bafcb3-efa2-44f6-989b-56bf358200a7

📥 Commits

Reviewing files that changed from the base of the PR and between 7145129 and 6e40c02.

📒 Files selected for processing (1)

• packages/lib/parse-dates.ts

💤 Files with no reviewable changes (1)

• packages/lib/parse-dates.ts

---

📝 Walkthrough

Walkthrough

parseRecurringDates now calculates initial and per-occurrence UTC offsets using the event’s configured timezone. A Vitest regression test sets the runtime timezone to Asia/Dubai and verifies that a weekly recurrence in America/New_York remains at 10:00 across the 2025 spring-forward DST transition.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly matches the main change: applying DST correction in the event timezone.
Description check	✅ Passed	The description directly explains the timezone/DST bug, the fix, and the added test, all matching the changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/lib/parse-dates.ts`:
- Around line 111-112: Remove the redundant “applying the DST offset” comment
immediately before the return statement in the date-parsing logic, leaving the
existing calculation unchanged.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 03dbc478-8fed-4731-b851-0fe4243d74dd

📥 Commits

Reviewing files that changed from the base of the PR and between f004349 and 7145129.

📒 Files selected for processing (2)

• packages/lib/parse-dates.timezone.test.ts
• packages/lib/parse-dates.ts