Repository navigation
feat: day-aligned sync window in local timezone - #3
Merged
Merged
Conversation
Change the sync window from rolling-relative-to-now to day-aligned
in the user's local timezone. Previously cli.py:69-70 computed:
start = now - window_past_days
end = now + window_future_days
So a sync at 14:23 saw [yesterday 14:23, +30d 14:23]. That caused
two real bugs:
1. Boundary churn: events near the past edge slid out of the window
mid-day, the daemon deleted them from Google, and the user
noticed events vanish for no apparent reason.
2. Flapping CREATE/DELETE pairs across consecutive runs: a noon sync
sees event X, a 3pm sync doesn't, the next sync re-creates it.
New helper _compute_sync_window(now, past_days, future_days, tz)
returns [midnight(today − past_days) local, midnight(today + future_days + 1) local)
as UTC-aware datetimes. The window is invariant within a local
calendar day. All-day events near the edge no longer flicker.
The log line now prints the window in local time and uses ")" for
the exclusive end so the format reflects the semantics.
5 new tests cover the alignment, day-invariance, zero-day edge case,
return-tz contract, and exclusive-end semantics — using a fixed
IDT (UTC+3) timezone so the tests don't depend on the runner's TZ.
177 tests pass (was 172).
Migration: behavioral, not schematic. The first sync after upgrade
may CREATE events newly in scope or DELETE events newly out of scope.
After that the window is stable.
Co-Authored-By: Claude Opus 4.7 <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
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.
Summary
Changes the sync window from rolling-relative-to-now to day-aligned in the user's local timezone. Same
window_past_days/window_future_daysconfig; new semantics inside the daemon.Why
Old behavior in
cli.py:69-70:So a sync at 14:23 saw
[yesterday 14:23, +30d 14:23]. Two real bugs:What changed
New helper
_compute_sync_window(now, past_days, future_days, tz)returnsas UTC-aware datetimes. Exclusive end (idiomatic Python). Window is invariant within a local calendar day — every sync of the same day evaluates the same boundaries.
The
sync.startlog line now prints the window in local time and uses)for the exclusive end, e.g.:Tests
5 new tests in
tests/unit/test_sync_window.py:test_window_aligns_to_local_midnighttest_window_invariant_within_a_local_daytest_window_zero_days_is_one_daytest_window_returns_utc_datetimestest_window_end_is_exclusiveUse a fixed IDT (UTC+3) timezone so they don't depend on the runner's TZ. 177 tests pass (was 172).
Migration
Behavioral, not schematic. First sync after upgrade may:
After that, the window is stable. No
state.dbmigration, no config schema change.Test plan
pytest tests/→ 177 passedogmac sync→ check~/Library/Logs/ogmac/sync.log:sync.start window=[YYYY-MM-DD..YYYY-MM-DD)shows day-aligned local datesreconcile create=…counts🤖 Generated with Claude Code