Configure logical day framing and multi-display capture#316
Open
rmqg wants to merge 10 commits into
Open
Conversation
Dayflow's "day" rolled over at a hard-coded 4 AM. That boundary was duplicated across ~15 call sites (timeline day bucketing, daily recap scheduling, day reprocessing, journal activity checks, weekly ranges, chat/dashboard date tools, and timeline review), so there was no single place to change it. This adds a user-configurable day start hour so people with non-standard schedules can attribute late-night activity to the correct day. Changes: - Add DayBoundaryPreferences: a UserDefaults-backed hour (key "dayBoundaryHour"), clamped to 0-23, defaulting to 4 to preserve the current behavior. - Route every day-boundary computation through DayBoundaryPreferences.boundaryHour instead of the literal 4. - Add a "Day start time" picker to Settings -> Other. The default is unchanged (4 AM), so existing users see no difference until they pick a different hour. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The first pass covered day *bucketing* but missed several places that independently hard-coded the 4 AM boundary for the visual hour axis and for minute-based day-window math: - Timeline hour axis: CanvasTimelineDataView and WeekTimelineGridView (startHour/endHour now derive from the boundary hour; the axis still spans a full 24h). - Minute-based day window / midnight-wrap normalization: WeeklyDonutBuilder, WeeklyOverviewBuilder, WeeklyDashboardBuilder (+HeatmapWorkflow), DailyWorkflowComputation, DaySummaryStats -- the "< 240 (4*60)" wrap threshold and the [4*60, 28*60] window now use DayBoundaryPreferences. - Add DayBoundaryPreferences.boundaryMinutes helper. Verified with a clean xcodebuild (Xcode 26.6): BUILD SUCCEEDED. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Two spots still assumed a pre-noon (4 AM) boundary and broke when the day start is later than noon (e.g. 4 PM): - normalizedTimelineDate() anchored the timeline's representative time to noon. Composed with getDayInfoFor4AMBoundary() (as DaySummaryView's timelineDayInfo and the recording projection window both do), a noon anchor with a boundary later than noon rolled the day back one extra day -- so "Your day so far" fetched the wrong (empty) day and the live "generating next card" indicator was clamped to the bottom of the axis. Anchor to the boundary hour instead. - nowCenteredTargetHourIndex() still hard-coded the 4 AM baseline for the scroll-to-now target; derive it from CanvasConfig.startHour. Verified with a clean xcodebuild (Xcode 26.6): BUILD SUCCEEDED, and confirmed at runtime with the day start set to 4 PM (stats populate and the live indicator sits at the current time). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Author
|
Follow-up: pushed two more commits that make the timeline hour axis + weekly/daily aggregation respect the boundary, and fix two spots that assumed a pre-noon boundary ( Built cleanly (Xcode 26.6) and runtime-tested end to end with the day start set to 4 PM: timeline axis starts at 4 PM, stats populate for the correct logical day, and the live indicator sits at the current time. |
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.
What & why
Dayflow previously hard-coded a 4 AM logical-day boundary and always labeled a cross-midnight day by its start date. A display-only End date implementation was unsafe because headings could look right while cards, exports, reprocessing, chat, and analytics still used another date.
This PR makes the boundary and label mode configurable while preserving the existing storage model. It also completes multi-display capture and a reproducible local development workflow.
Date model
Start date/End datecontrols the user-facing calendar label.Changes
dayFramingChangedrefreshes.scripts/dev.shwith stable local signing and automatic discovery of Xcode outside/Applications.Testing
./scripts/dev.sh testwith Xcode 27.0 (27A5218g): 15 tests passed.Visual verification
Verified the installed
/Applications/Dayflow.appin End date mode:Jul 11, 2026.2026-07-11, not the internal2026-07-10storage key.Dayflow timeline 2026-07-11 to 2026-07-11.Compatibility and remaining validation
Info.plistin Copy Bundle Resources.