mirror of
https://github.com/multica-ai/multica.git
synced 2026-06-17 03:38:32 +02:00
5900d8b637
* fix(issues): store start_date/due_date as DATE, not timestamp (MUL-2925) These fields are calendar days (the pickers offer no time-of-day), but were stored as TIMESTAMPTZ. A client serializing local midnight via toISOString() folded its timezone into the instant, so the day shifted by the local offset (GH #3618). Migrate the columns to DATE and parse/serialize date-only "YYYY-MM-DD". ParseCalendarDate still accepts legacy RFC3339 (truncated to the UTC day) so older clients keep working. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): render start_date/due_date as timezone-stable calendar days (MUL-2925) Pickers now emit date-only "YYYY-MM-DD" (local calendar day) instead of toISOString(), and every read formats via the shared @multica/core/issues/date helpers with timeZone:"UTC" so the day never shifts with the viewer's offset. The Gantt's existing UTC bucketing is now correct. Covers web/desktop pickers, quick-set menu, list/board/detail/activity, and the mobile due-date picker. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): address date-only review — loud-fail ambiguous dates, finish display sweep (MUL-2925) Review follow-ups on #3692: - ParseCalendarDate no longer silently truncates a legacy non-midnight RFC3339 to the wrong UTC day; it accepts only YYYY-MM-DD or an exact UTC-midnight instant and rejects ambiguous ones loudly. Adds util unit tests. - migration 112 pins the TIMESTAMPTZ->DATE conversion to UTC explicitly via AT TIME ZONE 'UTC' (was session-timezone dependent); down migration too. - Convert remaining date-change display sites to formatDateOnly: inbox detail label (web) and mobile activity + inbox labels (were new Date()+local format). - CLI --start-date/--due-date help now says YYYY-MM-DD, not RFC3339. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: J <j@multica.ai> Co-authored-by: multica-agent <github@multica.ai>
17 lines
1.0 KiB
SQL
17 lines
1.0 KiB
SQL
-- Issue start_date / due_date are calendar days: a user picks a day (the
|
|
-- pickers have no time-of-day input), so "Mar 1" must mean Mar 1 for everyone
|
|
-- regardless of timezone. Storing them as TIMESTAMPTZ folded the writer's
|
|
-- local midnight into a UTC instant, shifting the displayed day by the local
|
|
-- offset in non-UTC timezones (GH #3618 / MUL-2925). DATE carries no time or
|
|
-- timezone, so the picked day is preserved as-is.
|
|
--
|
|
-- Existing rows are truncated at the UTC day boundary, matching what the Gantt
|
|
-- already showed for them. `AT TIME ZONE 'UTC'` pins the conversion to UTC
|
|
-- explicitly so it does not depend on the migration session's TimeZone setting
|
|
-- (a bare `::date` cast would be session-timezone dependent). The original
|
|
-- local-day intent of legacy rows is unrecoverable from a bare instant, so this
|
|
-- is the best-effort conversion.
|
|
ALTER TABLE issue
|
|
ALTER COLUMN start_date TYPE DATE USING (start_date AT TIME ZONE 'UTC')::date,
|
|
ALTER COLUMN due_date TYPE DATE USING (due_date AT TIME ZONE 'UTC')::date;
|