fix(reports): bucket dashboard ticket trend in the user's timezone #274
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/pms-360-user-timezone-date-bucketing"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Date-bucketed renders disagreed about which day an instant belongs to: records timestamp UTC, but Calendar/Dispatch/"today" surfaces use browser-local time, so a ticket logged at 23:30 Pacific showed on the next UTC day in some views and the local day in others. The fix is a single source of truth: the active user's users.timezone (PMS-253).
This repo is mokosh-server plus the shared mokosh-types crate (consumed by the mokosh-apps WASM frontend per PMS-129). The enumerated UI surfaces (Time Entries list, weekly Timesheet, Calendar/Dispatch "today", dashboard "today" widget) render in mokosh-apps and are out of this repo's reach; the server contribution is the canonical bucketing primitive plus the one server-computed per-day bucket.
Adds mokosh_types::datetime with user_local_date(dt, tz) -> NaiveDate, user_today(now, tz), canonical_tz_name(tz) (falls back to UTC on an invalid/empty preference). Living in the shared crate means mokosh-apps reuses the exact same primitive for every frontend date bucket (proposed-approach items 1-4).
Rewrites the reports dashboard ticket_trend_30d to bucket via (created_at AT TIME ZONE $tz)::date with the 30-day window anchored to the user-local today, threading CurrentUser.timezone from the handler and the CSV export path (proposed-approach item 5).
Audit of date-bucket call sites in this repo (AC #4):
Tests: unit tests on the helper (Pacific 23:30 stays on the local day; LA vs London differ for the same instant; invalid/empty tz falls back to UTC) and an integration test proving the dashboard trend buckets the same UTC instant onto different days for a UTC vs an America/Los_Angeles viewer.
#PMS-360