occurrence_date is documented as a UTC key but is a local date in the request's zone #198

New issue

Closed

opened 2026-08-23 22:54:08 +00:00 by nalum · 0 comments

nalum commented

2026-08-23 22:54:08 +00:00

Owner

Event.occurrence_date is described in the proto as "an opaque YYYY-MM-DD key, UTC" (proto/api/core/v1/event.proto:56-58).

It is not UTC. The slot is day.Format("2006-01-02") on a time already expressed in the request's location (internal/domain/event.go:419,430), and it is parsed back with ParseInLocation against the same zone (validSlot in internal/services/event/occurrences.go). The key is the occurrence's local date in whichever zone the caller passed, which is exactly why SplitOccurrence and CancelOccurrence must be given the same zone as the ListOccurrences call that produced the row.

The comment is the only thing wrong — the behaviour is correct and deliberate. Left as is it invites a client to compute a slot key in UTC and address a different day. Found while reviewing the calendar design handoff.

Fix the comment, and check no client-side comment repeats the claim.

Update — fixed in PR #203 (2026-08-25)

The proto comment now states the key is a YYYY-MM-DD date in the zone the request carried, never UTC and never the row's own time_zone, and every request that carries a slot (SplitOccurrence, CancelOccurrence, and #209's JoinOccurrence/LeaveOccurrence) notes the zone must match the ListOccurrences call that showed it. Closes when the PR merges.

`Event.occurrence_date` is described in the proto as "an opaque YYYY-MM-DD key, UTC" (`proto/api/core/v1/event.proto:56-58`). It is not UTC. The slot is `day.Format("2006-01-02")` on a time already expressed in the request's location (`internal/domain/event.go:419,430`), and it is parsed back with `ParseInLocation` against the same zone (`validSlot` in `internal/services/event/occurrences.go`). The key is the occurrence's **local date in whichever zone the caller passed**, which is exactly why `SplitOccurrence` and `CancelOccurrence` must be given the same zone as the `ListOccurrences` call that produced the row. The comment is the only thing wrong — the behaviour is correct and deliberate. Left as is it invites a client to compute a slot key in UTC and address a different day. Found while reviewing the calendar design handoff. Fix the comment, and check no client-side comment repeats the claim. --- ## Update — fixed in PR #203 (2026-08-25) The proto comment now states the key is `a YYYY-MM-DD date in the zone the request carried, never UTC and never the row's own time_zone`, and every request that carries a slot (`SplitOccurrence`, `CancelOccurrence`, and #209's `JoinOccurrence`/`LeaveOccurrence`) notes the zone must match the `ListOccurrences` call that showed it. Closes when the PR merges.

nalum added the

bug

severity/low

labels

2026-08-23 22:54:08 +00:00

nalum referenced this issue

2026-08-23 22:54:30 +00:00

Order of work for the calendar redesign (#187-#198) #199

nalum added the

area/calendar

area/server

labels