Follow-up from #61 code review (R1). Non-blocking.
#61 added a server-computed dueStatus (overdue/today/this_week/later/none) derived from DateTime.Today. The phone deploy was fixed to set TZ=Asia/Kolkata on the backend service so 'today' matches the user's wall-clock day (the proot guest otherwise runs in UTC).
The GCP demo deploy (scripts/deploy-gcp.ps1 + its systemd unit) has no equivalent. The public demo's dueStatus will compute against the VM's timezone (likely UTC), so 'today' / 'this_week' can be off by a day near midnight.
Fix: set an explicit TZ on the GCP backend service (systemd Environment=TZ=... or the VM timezone) matching the intended demo locale. Low urgency - the demo DB resets every 6h and it is a showcase, not the user's real data.
Source: code review on branch feature/due-status-and-tool-hints-#61. Tracking issue #61.
Follow-up from #61 code review (R1). Non-blocking.
#61 added a server-computed
dueStatus(overdue/today/this_week/later/none) derived fromDateTime.Today. The phone deploy was fixed to setTZ=Asia/Kolkataon the backend service so 'today' matches the user's wall-clock day (the proot guest otherwise runs in UTC).The GCP demo deploy (
scripts/deploy-gcp.ps1+ its systemd unit) has no equivalent. The public demo'sdueStatuswill compute against the VM's timezone (likely UTC), so 'today' / 'this_week' can be off by a day near midnight.Fix: set an explicit TZ on the GCP backend service (systemd
Environment=TZ=...or the VM timezone) matching the intended demo locale. Low urgency - the demo DB resets every 6h and it is a showcase, not the user's real data.Source: code review on branch
feature/due-status-and-tool-hints-#61. Tracking issue #61.