fix(darwin): correct timezone offset across month/year boundaries - #4
Merged
Merged
Conversation
computeTimezoneOffsetMinutes converted each timezone's wall clock to `day*1440 + h*60 + m` using day-of-month, then subtracted the two. When the current instant lands on different calendar days across a month boundary (e.g. Jul 31 locally but already Aug 1 in Tokyo), day-of-month jumps 31 -> 1 instead of 31 -> 32, injecting a ~30-day (43200-min) error — so the launchd CalendarInterval timezone adjustment was wrong for far-apart timezones around month ends. Use the full year/month/day via Date.UTC so the subtraction is correct across month and year boundaries. Add a regression test pinned (fake timers) to 2026-07-31T23:30Z, the instant that reproduced the failure. Confidence: high Scope-risk: narrow Not-tested: leap-second edge (not representable by Intl parts) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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
Fix
computeTimezoneOffsetMinutes(src/schedulers/darwin.ts) to stay correct across month/year boundaries.Bug
It converted each timezone's wall clock to
day*1440 + h*60 + musing day-of-month, then subtracted the two readings. When the current instant falls on different calendar days that straddle a month boundary — e.g. it's still Jul 31 in UTC/NY but already Aug 1 in Tokyo — day-of-month jumps31 → 1instead of31 → 32, injecting a ~30-day (43,200-min) error.Symptom: the
computeTimezoneOffsetMinutes › produces consistent relative offsetstest fails around month-end withexpected -43860 to be greater than or equal to 780. This is date-triggered and pre-existing onmain(it passes most days), and the same miscalculation corrupts the launchdCalendarIntervaltimezone adjustment for far-apart timezones around month boundaries.Fix
Use the full year/month/day via
Date.UTC(y, mo-1, d, h, m)/60000, so the subtraction is correct across month and year boundaries. Adds a regression test pinned (fake timers) to2026-07-31T23:30Z— the exact instant that reproduced the failure.Verification
npm test— 341 passed (incl. new regression test)npm run typecheck/lint/build— green🤖 Generated with Claude Code