Repository navigation
fix(macos): keep the primary timezone hint when the first primary has no zone - #5240
Merged
Merged
Conversation
… no zone `CalendarTimeZoneHint.pick` is a mirror of web `pickCalendarTimeZoneHint`, which its own doc comment names as the owner. The two had drifted: web picks the first primary that actually carries a zone, while Swift latched onto the first primary unconditionally and, when that one had no zone, fell through to the generic non-UTC scan instead of trying the next primary. With two connected accounts where the first account's primary reports no timeZone and a non-primary calendar is ordered between the primaries, web resolves the second primary's zone and macOS resolved the earlier non-primary zone. Nothing on either side pinned that case, so the Auto zone could disagree across platforms and land the day grid on a different day at the UTC boundary, which is the failure #5229, #5232 and #5235 were written to close. Mirrors web's truthiness test through one `usableZone` helper, so an absent or empty zone no longer consumes the primary preference, and pins the same vector on both sides. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HmwVQE5bxVJUZtQKo3JX3L
tyler-dane
enabled auto-merge
November 12, 2026 11:34
Contributor
|
Boot bundle: 576.8 KB gzip (+0.0 KB vs main) |
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
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.
Scheduled tech-debt sweep for 2026-11-12. No issue; the finding is the sweep's own.
What and why
CalendarTimeZoneHint.pickis a mirror of webpickCalendarTimeZoneHint, which its own doc comment names as the owner, and the two had drifted. Web picks the first primary calendar that actually carries a zone (find(c => c.isPrimary && c.timeZone)); Swift bound the first primary unconditionally (first(where: { $0.isPrimary })) and, when that one had no zone, let the wholeif letchain fail and fell through to the generic non-UTC scan instead of trying the next primary. With two connected accounts where the first account's primary reports notimeZoneand a non-primary calendar is ordered between the primaries, web resolves the second primary's zone and macOS resolved the earlier non-primary zone.timeZoneisnullablein the sharedcalendar.contractsschema, so that state is representable, and multiple primaries are the normal multi-account shape. Nothing on either side pinned the case, so the Auto zone could disagree across platforms and land the day grid on a different day at the UTC boundary, which is the failure #5229, #5232 and #5235 were written to close, reached through the mirror instead.The fix routes both sides of the Swift predicate through one
usableZonehelper so an absent or empty zone no longer consumes the primary preference, and pins the same vector on both platforms (webcalendar-timezone-hint.test.ts, macOSCalendarTimeZoneHintTests.swift) so the mirror cannot drift silently again. Behavior preserving on web: the new web vector passes against the unchanged implementation, which is what identifies Swift as the drifted copy. macOS behavior changes only in the divergent case, to match the declared owner.Examined and deliberately left alone, recorded in
judged-fine.mdso the next sweep does not redo it:DayCalendarColumns.swiftresolves its no-events fallback as "first primary, then first ordered calendar", while web'sgetDayViewCalendarsgoes throughgetDefaultTargetCalendar, which additionally requires the primary to be a writable provider calendar and falls back to the local calendar first. A real divergence, but mirroring web needsisWritableProviderCalendarandgetLocalCalendarsemantics CompassKit does not model, which is a contract decision rather than debt a sweep may settle. Flagged for a human.EdgeFocusHint.swift(feat(web): edge-focus sidebar contextual hints (#5179) #5231). Restates the mode-announcement strings and theTabkeycap as literals. Inherent cross-platform duplication; CompassKit cannot import@compass/core, and the two sides render different shapes.wholeEventMoveKeysinedge-focus-hint.parts.ts(feat(web): edge-focus sidebar contextual hints (#5179) #5231). Hardcodes the five-key timed arrow list besideedgeMoveKeysderiving its timed case fromKEYMAP.moveEvent.timedEdgeKeycaps. No owning export exists to drift from, so naming one would be a fix larger than the problem.Verify
bun run verify --strictBaseline against
origin/main:bun cli contracts:swift --checkandbun cli desktop:export --checkboth pass.Note: the Swift test added here runs in CI only. There is no Xcode on the sweep machine, so
test-macos.ymlis what actually exercises the fixed path; the local verdict covers the web vector, types, lint, knip, a11y and e2e.Generated by Claude Code