Skip to content

fix: filter natural-language date components consistently - #113

Closed
udondan wants to merge 6 commits into
keith:mainfrom
udondan:fix-flaky-date-tests
Closed

udondan wants to merge 6 commits into
keith:mainfrom
udondan:fix-flaky-date-tests

Conversation

@udondan

@udondan udondan commented Sep 13, 2026

Copy link
Copy Markdown

Summary

  • components(from:) in NaturalLanguage.swift returned the unfiltered result of Calendar.dateComponents(in:from:) whenever a parsed date included a significant time, instead of narrowing it to the declared component set the way the no-time branch already did. On newer macOS SDKs that method also populates .dayOfYear, silently leaking an extra field into DateComponents values used for reminder due dates. Both branches now derive from the same explicit component set via a zone-adjusted Calendar.
  • testTonight hardcoded an expected hour of 19:00, but NSDataDetector's interpretation of "tonight" is an OS/locale-dependent implementation detail that has changed across macOS versions (now 18:00 here), making the test flaky. Loosened it to assert "today, on the hour, within an evening window" instead of an exact time.

Test plan

  • swift test --filter RemindersTests.NaturalLanguageTests — all 11 tests pass
  • make build-release succeeds
  • swift build -Xswiftc -warnings-as-errors (CI-matching build) succeeds

udondan and others added 6 commits September 13, 2026 09:52
-Xswiftc -warnings-as-errors was applied to the whole build graph,
so any warning surfacing in swift-argument-parser under a newer
Swift compiler broke the build. Scope the flag to our own targets
via Package.swift swiftSettings instead, bump swift-argument-parser
past 1.3.x to pick up its Sendable-conformance fixes, and migrate
off its now-deprecated single-argument completion closure API.
chore: fix build-release failing under newer Swift toolchain
chore: add CLAUDE.md and VS Code launch configuration
When a parsed date included a significant time (e.g. "tomorrow 9pm"),
components(from:) returned the unfiltered result of
Calendar.dateComponents(in:from:) instead of narrowing it to the
declared component set like the no-time branch already did. On newer
macOS SDKs that method also populates .dayOfYear, silently leaking an
extra field into DateComponents values used for reminder due dates.
Both branches now derive from the same explicit component set via a
zone-adjusted Calendar.
…oice

The exact hour NSDataDetector picks for "tonight" is an OS/locale
implementation detail that has changed across macOS versions (18:00 vs
the previously hardcoded 19:00), making the test flaky. Assert it
resolves to today, on the hour, within a broad evening window instead
of an exact time.
@udondan udondan closed this Sep 13, 2026
@udondan

udondan commented Sep 13, 2026

Copy link
Copy Markdown
Author

sry, only meant for my fork...

@udondan
udondan deleted the fix-flaky-date-tests branch September 13, 2026 10:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant