Repository navigation
calendar: read all-day events with end == start as one day - #184
Merged
Merged
Conversation
User testing (2026-09-28) showed what the unreadable events were: all 21 all-day events in a test calendar had end.date equal to start.date, e.g. start "2026-04-02", end "2026-04-02" (logged through the collector). Google Calendar shows them as one day; Google's own writes use an exclusive end, the day after. project() now accepts end == start and projects the exclusive end, so they import as one-day events and a later write-back sends the exclusive end. An end before the start is still unreadable. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
michielbdejong
added a commit
that referenced
this pull request
Sep 28, 2026
…#184) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
michielbdejong
pushed a commit
that referenced
this pull request
Sep 29, 2026
main gained calendar changes after this branch generated apps/calendar/0.1.0/ui.js (#181 unreadable Google events, #183 the user-testing log hook, #184 all-day events with end == start, #187 "Jump to latest event"). 0.1.0 is not on main yet, so its bytes and catalog integrity are regenerated with `apps.mjs write calendar`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
michielbdejong
pushed a commit
that referenced
this pull request
Sep 29, 2026
#184 reads an all-day event whose end.date equals its start.date as that one day with an exclusive end, in project(). #172's End day copies the projected exclusive end, so such an event gets the day after as End day and the host Calendar view (start <= day < end) draws it on its one day. The new sync test covers both: end == start on the imported one-day event is no change, and a move to another day with end == start imports as that day with the next day as End day. Co-Authored-By: Claude Opus 5.5 <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.
Follow-up to #181, confirmed by the user-testing log collector (#182, #183).
After #181, a sync of the tester's calendar no longer failed, but it imported 0 events: all 21 were skipped as unreadable. The collector logged the raw values, for example:
All of them are all-day events with
end.date == start.date. Google Calendar's UI shows them as one day. Google's own writes use an exclusive end (the day after), which is whatproject()required.Change
project()acceptsend.date == start.dateand projects the exclusive end (2026-12-31→2027-01-01, across a year boundary in the test). They import as one-day events, and a later write-back sends the exclusive end.Checks
typecheckandunitlanes: passed (94 tests)oxlint: no errors🤖 Generated with Claude Code