fix(frontend): parse cron scheduled session times as UTC

[machadovilaca]

cron-parser defaults to the browser's local timezone, so "Next 3 runs" shows times offset from UTC even though the cron expression is stored and executed as UTC

shows 7:30 AM UTC (8:30 AM GMT+1) for next run

shows a different time: At 08:30 AM UTC

Fixed by passing { tz: "UTC" } to CronExpressionParser.parse() so next run calculations match UTC

Summary by CodeRabbit

• Bug Fixes
  • Fixed cron expression parsing to explicitly use UTC timezone instead of relying on system defaults, ensuring consistent and predictable scheduling behavior across all environments.

[netlify]

✅ Deploy Preview for cheerful-kitten-f556a0 canceled.

Name	Link
🔨 Latest commit	051279a
🔍 Latest deploy log	https://app.netlify.com/projects/cheerful-kitten-f556a0/deploys/69fca87dfbf3120008ede75a

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: fd1730be-7181-4719-b081-d2dfc63ba9a3

📥 Commits

Reviewing files that changed from the base of the PR and between 1b4ec53 and e10dfe8.

📒 Files selected for processing (1)

• components/frontend/src/lib/cron.ts

---

📝 Walkthrough

Walkthrough

The cron parser in getNextRuns now explicitly specifies UTC timezone via an options parameter instead of relying on default timezone behavior. Error handling and return logic remain unchanged.

Changes

Cron Timezone Configuration

Layer / File(s)	Summary
Timezone Specification components/frontend/src/lib/cron.ts	CronExpressionParser.parse() call adds explicit { tz: "UTC" } option to ensure consistent UTC-based run date calculations.

🚥 Pre-merge checks | ✅ 8

✅ Passed checks (8 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	Title follows Conventional Commits format (fix(frontend): ...) and accurately describes the main change: fixing UTC timezone parsing for cron expressions in the frontend.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
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.
Performance And Algorithmic Complexity	✅ Passed	Single parameter addition (tz: UTC) to cron parser. No algorithmic complexity change, bounded iteration (1-3 runs), calls properly memoized in React. No regressions.
Security And Secret Handling	✅ Passed	No security violations found. Frontend utility file adding { tz: "UTC" } parameter to cron parser. No secrets, injection vectors, or sensitive data leakage detected.
Kubernetes Resource Safety	✅ Passed	PR modifies only frontend TypeScript code (cron timezone parsing). Contains no Kubernetes manifests, deployments, or infrastructure resources. Kubernetes Resource Safety check is not applicable.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

✨ Simplify code

• Create PR with simplified code

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

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 and usage tips.}

[machadovilaca]

/cc @jsell-rh

[jsell-rh]

@machadovilaca Nice catch, thank you!

Do you think it would be better to consistently show times in the browser's timezone? Including making the cron expression entry assume browser's TZ.

Especially for the folks that aren't +/- 1 UTC, the offset calculation can be a point of friction.

It would require a bit of transformation to take the hour from the cron entry on the frontend so that the user inputs in their local TZ and the API call uses UTC, but it might be a nice quality of life improvement.

What do you think?

[machadovilaca]

@machadovilaca Nice catch, thank you!

Do you think it would be better to consistently show times in the browser's timezone? Including making the cron expression entry assume browser's TZ.

Especially for the folks that aren't +/- 1 UTC, the offset calculation can be a point of friction.

It would require a bit of transformation to take the hour from the cron entry on the frontend so that the user inputs in their local TZ and the API call uses UTC, but it might be a nice quality of life improvement.

What do you think?

@jsell-rh i think that makes sense
but maybe something like what's shown on the last run column

**Last Run**
9:50 AM UTC (10:50 AM GMT+1)

basically

**Schedule (UTC)**
At 08:30 AM
30 8 * * *

would become

**Schedule**
At 08:30 AM UTC (09:30 AM GMT+1)
30 8 * * *

should this be done as part of this PR, or in a follow-up?

[jsell-rh]

@machadovilaca, that looks good to me.

I'll approve this workflow to run, and kindly ask that you open a follow-up with the local TZ changes.

Thank you!