max / goingson

Give events explicit timezone semantics; expose task recurrence in go-mcp An event was a bare UTC instant and its recurrence rule was expanded against system_tz() at read time, which made the schedule a property of the reading machine rather than of the data. The same database opened in Denver and in Lisbon produced different local times and different weekdays, because a rule anchored at 01:00 UTC is Monday in one and Tuesday in the other. Events now carry a kind, following iCalendar's distinction: relative civil wall clock, no zone. "06:00 wherever I am", so a personal routine follows the user instead of staying pinned to a longitude. local civil wall clock plus an IANA zone. Correct across that zone's DST for every reader. iCalendar's TZID. absolute a fixed instant, displayed in the reader's zone. How every row was implicitly treated until now. For the civil kinds the wall clock is the truth and start_time/end_time hold a materialized UTC projection, kept so every existing range query, index and ORDER BY works untouched. The projection is derived, never authoritative, which is also why the civil columns are what a sync peer trusts: a relative event synced to a machine in another zone must be re-materialized there, not overwritten with this one's instant. A startup pass recomputes it when the system zone changes, gated on a device-local marker so an ordinary launch does one SELECT and no writes. Migration 063 is behaviour-preserving: every existing row becomes absolute. Reclassifying a routine is a deliberate act on a user's own data, not something a migration should guess, so it lives in scripts/classify_routines_relative.sql. Imports stay absolute; the .ics parser resolves TZID and Z to an instant before we see it, and a foreign calendar never describes "whenever I happen to be". Separately, create_task, bulk_import_tasks and update_task now take the same recurrence argument the event tools do. That exposed a gap: complete_task went through the plain repository complete, so a recurring task would have closed with no successor. It now goes through complete_recurring, and the logic that builds the successor moved out of the desktop command layer into goingson_core::next_recurring_task, since the MCP peer is a second writer and two copies would be two answers to what recurring completion means. Two bugs found on the way. The event form posted civil times space-separated, the shape SQLite stores, which chrono's ISO 8601 deserializer rejects outright, so every relative or local event created from the UI would have failed at the serde boundary. And getEventFormFields read event.start_time where EventResponse serializes camelCase, so edit mode had always silently fallen back to the current time instead of the event's own.