Trial 4 follow-up: choose one calendar-day rule

[raghubetina]

Parent: Ben/Jelani feedback decision tracker #43. Research recommendations remain pending unless a prior decision is explicitly identified.

Give the Habit Tracker one consistent calendar-day rule

Research packet — 2026-09-19. Original finding 47. Application continuation defect, not a Compiler State Machine defect. No application edits or shared-database use were performed in this research.

Suggested owner: track under the new feedback master in firstdraft/drawing-board as a trial follow-up, with links to trial 4. No existing trial-4 issue was returned by the authenticated issue listing. If work is assigned to that repository later, create/link the application issue then. Do not add an FP timezone choice to this repair by implication.

Report and exact attribution

Jelani's trial-4 prompt asks for a snoozed reminder to expire at the end of the day. It does not specify Central time. Central was selected in the subsequent application implementation; it should not be retroactively presented as an approved user requirement.

Current trial main is still 231f75783e9fca53daf984f3f9f7c11577253009. The generated baseline is 2826e4bec0d29b2d14b8950984a3e7bcd360fe58. Commit 8510df7cc7f8861946e2582b36dd40c2c70a34dc adds day defaults and the reminder-expiry job; 231f757 adds the dashboard. The baseline did not contain this dashboard/job interaction.

The dashboard uses Date.current and selects reminder_on: @today. The expiry job computes the current day in America/Chicago. config/application.rb leaves the application time zone unset, so Rails defaults to UTC. Both new model day defaults follow Date.current too.

At June 2, 2031, 04:00 UTC, Chicago is still June 1, 23:00. A June 1 snoozed reminder correctly survives the job's local-day check but disappears from the dashboard's June 2 query. The September 13 request reproduction reported 17 tests / 88 assertions / one failure at precisely this boundary. Existing request/job tests passed separately; they did not compose their two definitions of “today.”

Fresh bounded reproduction

An isolated no-database probe on Ruby 4.0.6 and pinned Active Support/Active Job 8.1.3.1 reconfirms the value mismatch:

Instant	Dashboard with UTC app	Expiry in Chicago	Dashboard with Chicago app
2031-06-02 04:00 UTC	June 2	June 1	June 1
2031-01-16 05:00 UTC	January 16	January 15	January 15

It also verifies Active Job serializes the creator's Time.zone and restores it when execution starts in another zone. This is value/job-serialization evidence, not a fresh application request, scheduler or email qualification. Local receipts: time-zone-probe.rb and time-zone-probe.json beside this packet.

Framework convention and prior art

Rails already separates application civil time from UTC persistence. Set config.time_zone for a one-zone application; use Time.use_zone around a request or operation when a product genuinely has per-user/per-tenant zones. Use Date.current/Time.current in that context. Do not replace UTC database storage or implement manual fixed-offset arithmetic; named zones handle daylight-saving changes. Rails configuration, pinned Date.current, Rails Time.use_zone.

Active Job already captures the zone on initialization and serialization, then executes inside it. A custom propagation mechanism is unnecessary. Recurring scheduler configuration remains a separate concern; a recurring task does not originate in a particular user's request. Pinned job serialization, execution context.

Options

1. One app-wide named zone — recommended for this single-user trial. If Chicago is the intended product day, set the ordinary Rails application zone and derive dashboard/default/expiry dates consistently. This is a small source repair; no new model field or FP feature is needed.
2. UTC everywhere. Equally coherent if intentionally chosen, but daily tracking would change day in the Chicago evening and differ from the current expiry assumption.
3. Per-user zones or an all-outstanding-reminders dashboard. Legitimate future product choices, but they change scope rather than merely repairing the inconsistency. An outstanding-reminders section might also address late jobs; it does not itself define the date used for logging or defaults.

One owner question

For this single-user trial, should “today” and “end of day” consistently mean America/Chicago throughout the app, using normal Rails time-zone configuration?

Acceptance

• Verify day defaults, dashboard membership and expiry against one explicit rule at late-evening summer and winter boundaries, midnight, and a daylight-saving transition.
• Preserve explicitly selected dates; do not rewrite stored date values merely because the application display zone changes.
• Check form round trips for scheduled_at and the job's selected instant, not just formatting.
• Decide and document the existing 15-minute expiry sweep tolerance. Setting a time zone does not make an asynchronous sweep occur exactly at midnight.
• Run the original failing dashboard request against the repair, and retain a focused application regression that a maintainer would naturally write.
• Feed the general lesson into continuation guidance only if useful: consequential day/zone semantics should be resolved when implementing daily features. No blanket timezone questionnaire for every Plan.