fix(time): bucket every date-render in the user's timezone (PMS-360)

YousifShkara commented

2026-06-16 23:47:26 +02:00

Owner

Date-bucketed surfaces disagreed about which day an instant belongs to: Time Entries and Timesheet bucketed via UTC, Calendar and Dispatch used browser-local time, so a time entry logged at 23:30 Pacific stamped UTC=Jun 16 showed on Jun 15 in some views and Jun 16 in others. Same hour, two days. The fix is a single source of truth: the active user's users.timezone (PMS-253 made this column user-configurable), threaded through every date-bucket call site.

Adds utils::datetime::user_local_date(dt, tz) and user_today(tz) on top of a new chrono-tz dependency, plus a user_timezone() AuthContext reader that falls back to UTC when the context is absent or the preference is empty (matches the server-side canonical_tz_name introduced by the mokosh-server PMS-360 PR so the two crates agree on the fallback).

Switched call sites:

pages/time.rs: Time Entries today/week buckets, new-entry default date.
pages/time.rs: Timesheet week anchor.
pages/dashboard.rs: Hours-This-Week card week anchor.
pages/calendar.rs: Calendar today_real (was Local::now), DispatchBoard today_real (same).

Unit tests pin the regression directly: a 23:30 Pacific instant buckets to Jun 15 in Los Angeles tz / Jun 16 in UTC; a Los Angeles viewer and a London viewer disagree about the day for the same instant (PMS-360 AC #1, #2); the fallback maps empty / stale / unknown tz strings to UTC.

Server-side dashboard trend bucketing landed separately on mokosh-server (PR #260 / commit e56be90); this PR is the SPA companion the server commit message called out as required follow-up.

Out of scope: no chrono-tz call sites in the server-computed dashboard widgets (those buckets come from the server already), no change to PMS-253 absolute datetime display (those still render through the existing browser-local format_user_datetime).

#PMS-360

Date-bucketed surfaces disagreed about which day an instant belongs to: Time Entries and Timesheet bucketed via UTC, Calendar and Dispatch used browser-local time, so a time entry logged at 23:30 Pacific stamped UTC=Jun 16 showed on Jun 15 in some views and Jun 16 in others. Same hour, two days. The fix is a single source of truth: the active user's users.timezone (PMS-253 made this column user-configurable), threaded through every date-bucket call site. Adds `utils::datetime::user_local_date(dt, tz)` and `user_today(tz)` on top of a new chrono-tz dependency, plus a `user_timezone()` AuthContext reader that falls back to UTC when the context is absent or the preference is empty (matches the server-side `canonical_tz_name` introduced by the mokosh-server PMS-360 PR so the two crates agree on the fallback). Switched call sites: - pages/time.rs: Time Entries today/week buckets, new-entry default date. - pages/time.rs: Timesheet week anchor. - pages/dashboard.rs: Hours-This-Week card week anchor. - pages/calendar.rs: Calendar `today_real` (was Local::now), DispatchBoard `today_real` (same). Unit tests pin the regression directly: a 23:30 Pacific instant buckets to Jun 15 in Los Angeles tz / Jun 16 in UTC; a Los Angeles viewer and a London viewer disagree about the day for the same instant (PMS-360 AC #1, #2); the fallback maps empty / stale / unknown tz strings to UTC. Server-side dashboard trend bucketing landed separately on mokosh-server (PR #260 / commit e56be90); this PR is the SPA companion the server commit message called out as required follow-up. Out of scope: no chrono-tz call sites in the server-computed dashboard widgets (those buckets come from the server already), no change to PMS-253 absolute datetime display (those still render through the existing browser-local `format_user_datetime`). #PMS-360

YousifShkara self-assigned this

2026-06-16 23:47:26 +02:00

YousifShkara added 1 commit

2026-06-16 23:47:26 +02:00

fix(time): bucket every date-render in the user's timezone (PMS-360)

Check / clippy + fmt + tests (pull_request) Successful in 2m33s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

ce8b6ea578

Date-bucketed surfaces disagreed about which day an instant belongs to: Time Entries and Timesheet bucketed via UTC, Calendar and Dispatch used browser-local time, so a time entry logged at 23:30 Pacific stamped UTC=Jun 16 showed on Jun 15 in some views and Jun 16 in others. Same hour, two days. The fix is a single source of truth: the active user's users.timezone (PMS-253 made this column user-configurable), threaded through every date-bucket call site.

Adds `utils::datetime::user_local_date(dt, tz)` and `user_today(tz)` on top of a new chrono-tz dependency, plus a `user_timezone()` AuthContext reader that falls back to UTC when the context is absent or the preference is empty (matches the server-side `canonical_tz_name` introduced by the mokosh-server PMS-360 PR so the two crates agree on the fallback).

Switched call sites:
- pages/time.rs: Time Entries today/week buckets, new-entry default date.
- pages/time.rs: Timesheet week anchor.
- pages/dashboard.rs: Hours-This-Week card week anchor.
- pages/calendar.rs: Calendar `today_real` (was Local::now), DispatchBoard `today_real` (same).

Unit tests pin the regression directly: a 23:30 Pacific instant buckets to Jun 15 in Los Angeles tz / Jun 16 in UTC; a Los Angeles viewer and a London viewer disagree about the day for the same instant (PMS-360 AC #1, #2); the fallback maps empty / stale / unknown tz strings to UTC.

Server-side dashboard trend bucketing landed separately on mokosh-server (PR #260 / commit e56be90); this PR is the SPA companion the server commit message called out as required follow-up.

Out of scope: no chrono-tz call sites in the server-computed dashboard widgets (those buckets come from the server already), no change to PMS-253 absolute datetime display (those still render through the existing browser-local `format_user_datetime`).

#PMS-360