Repository navigation
Conversation
Bun.cron.parse() and the in-process Bun.cron(schedule, handler) changed from UTC to local time in #35122 as part of the 1.4 breaking changes (#28792). The Time zone section described the new behavior but never mentioned that it changed, so users upgrading from 1.3.x had no pointer to { tz: "UTC" } to restore the old semantics. Adds a <Note> callout in docs/runtime/cron.mdx and a line in the CronOptions.tz JSDoc so the migration path is visible in both the rendered docs and the IDE tooltip. No runtime warning is added: none of the other ~40 breaking changes in #28792 warn at runtime, the local-time default matches crontab/launchd/ Task Scheduler and node-cron/croner, and the suggested heuristic (no tz option, TZ not UTC) would fire for essentially every developer on every process start with no way to know whether UTC was actually intended.
|
Warning Review limit reached
Next review available in: 15 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
Comment |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — docs-only migration note for the v1.4 UTC→local cron time-zone change.
What was reviewed:
- MDX: backtick-wrapped
{ tz: "UTC" }inside<Note>matches existing usage (e.g.docs/runtime/sql.mdx,docs/bundler/hot-reloading.mdx), so no MDX/JSX brace-parsing issue. bun.d.ts: JSDoc-only addition onCronOptions.tz; no type surface changed.- Claim consistency: surrounding docs and the
Bun.cron.parseJSDoc already state local-time default, so the "prior to v1.4" note is additive and non-contradictory.
Extended reasoning...
Overview
Adds a <Note> callout under the Time zone heading in docs/runtime/cron.mdx and one sentence to the CronOptions.tz JSDoc in packages/bun-types/bun.d.ts, both stating that prior to Bun v1.4 cron schedules were interpreted in UTC and that { tz: "UTC" } restores the old behavior. No runtime code is touched.
Security risks
None. Pure documentation/JSDoc; no executable code, no type-surface change, no build-script or config changes.
Level of scrutiny
Low. This is a two-hunk docs change describing a behavior change that already shipped in #35122. The only things worth checking were (a) MDX correctness — curly braces inside JSX children can be parsed as expressions, but here they are inside inline-code backticks, and the same pattern is already used in docs/runtime/sql.mdx, docs/bundler/hot-reloading.mdx, and several other .mdx files; and (b) that the .d.ts edit is comment-only, which it is (verified against the current tz?: string declaration).
Other factors
The PR description confirms prettier --check and the bun-types integration test both pass. The surrounding prose in cron.mdx and the parse() JSDoc already document the local-time default, so the new note is consistent with its neighbors. The bug-hunting system found no issues. There are no prior human review comments to address.
|
This PR may be a duplicate of:
🤖 Generated with Claude Code |
|
Not a duplicate of #36463: that PR adds a standalone 1.3→1.4 upgrade guide at |
The in-process Bun.cron(schedule, handler, options?) overload JSDoc never mentioned time zone or its own options parameter, so the one IDE tooltip an upgrader actually hovers (their existing Bun.cron(expr, fn) call) carried neither the local-time default nor the v1.4 note. Adds a Time zone subsection and @PARAM options, mirroring parse().
|
Docs/JSDoc-only: the diff is a |
There was a problem hiding this comment.
LGTM — docs-only version-change note for the cron time-zone default.
What was reviewed:
<Note>callout incron.mdxuses backtick-wrapped{ tz: "UTC" }inside JSX children — same pattern already renders indocs/runtime/sql.mdx:198anddocs/bundler/hot-reloading.mdx:55.- New
@param optionsand@throwson the in-process overload match the actual signature (options?: CronOptionsat bun.d.ts:7737) and the existing prose incron.mdx("Throws … if the time-zone name is unknown"). CronOptions.tznote is consistent with theparse()JSDoc that already documents the local-zone default.
Extended reasoning...
Overview
Two files touched, both documentation: a <Note> callout added under the Time zone heading in docs/runtime/cron.mdx, and JSDoc additions in packages/bun-types/bun.d.ts (a one-liner on CronOptions.tz, a new ### Time zone subsection + @param options on the in-process Bun.cron(schedule, handler, options?) overload, and an expanded @throws clause covering invalid tz). No runtime code, no .rs/.cpp, no test changes.
Security risks
None. Prose and JSDoc only; nothing executable is modified.
Level of scrutiny
Low. This is a migration note for a behavior change that already landed in #35122. The only correctness concerns are (a) MDX parseability of `{ tz: "UTC" }` inside a JSX <Note> child, and (b) whether the new JSDoc matches the real signature. I verified (a) against identical existing usage in docs/runtime/sql.mdx and docs/bundler/hot-reloading.mdx, and (b) against the overload signature at bun.d.ts:7737, which does take options?: CronOptions. The @throws addition ("options.tz is not a valid IANA name") mirrors the existing prose in cron.mdx ("Throws a TypeError if … the time-zone name is unknown").
Other factors
The PR description reports prettier --check and test/integration/bun-types/bun-types.test.ts passing. The duplicate-PR bot flagged #36463, but that PR touches a separate upgrade-guide file and the author already addressed the overlap. No prior human review comments to resolve. The bug-hunting pass found nothing.
|
Updated 8:11 AM PT - Jul 30th, 2026
✅ @robobun, your commit 11c5758a8072e75e2a5a8077fbe54825976290e1 passed in 🧪 To try this PR locally: bunx bun-pr 36461That installs a local version of the PR into your bun-36461 --bun |
|
Closing this PR because it has been inactive for more than 90 days. |
Part of #28792. Follow-up to #35122.
What
Bun.cron.parse()and the in-processBun.cron(schedule, handler)switched from UTC to local time in #35122. The Time zone section now describes the new behavior but never mentions that it changed, so a 1.3.x user reading it would assume local time was always the default and miss that their schedules will shift on upgrade.This adds:
A
<Note>callout under Time zone indocs/runtime/cron.mdx:A Time zone subsection and
@param optionson the in-processBun.cron(schedule, handler, options?)overload JSDoc inbun.d.ts. cron: interpret Bun.cron.parse() and in-process schedules in local time; add { tz } option #35122 added theoptionsparameter to the signature without documenting it, so hovering an existingBun.cron(expr, fn)call in an editor showed neither the local-time default nor the escape hatch. This closes the asymmetry withparse(), which already documented both.A one-line "prior to v1.4 the default was UTC" on
CronOptions.tz.The v1.3.14 docs stated the UTC behavior explicitly (
git show bun-v1.3.14:docs/runtime/cron.mdxline 35: "return the next matchingDatein UTC"), so there are shipped releases whose documented semantics differ.Why docs, not a runtime warning
A one-time stderr warning (first call per process when
{ tz }is omitted and the process TZ isn't UTC) was considered and rejected:node-cron,croner). A user writingBun.cron("0 9 * * *", handler)for the first time almost certainly means 9 AM local, so the warning's heuristic can't distinguish "wanted the old UTC behavior" from "wants what every other cron does".{ tz }everywhere.Verification
bunx prettier --check docs/runtime/cron.mdx packages/bun-types/bun.d.tspasses.bun test test/integration/bun-types/bun-types.test.tspasses (14/14).{ ... }inside<Note>matches existing usage indocs/runtime/sql.mdxanddocs/bundler/hot-reloading.mdx.Docs-only; no runtime change.