A Systematic Timezone Audit: From Smell to Eight Fix PRs in One Day
Context
Picket is a multi-tenant commerce platform for small farms. Farmers use it to manage subscription CSAs, track orders, run fulfillment batches, and review analytics. Date handling is core to the product — subscription cutoffs, delivery schedules, weekly sales email timing, monthly export windows — and the admin portal surfaces dates to growers across a dozen different views and routers.
By May 2026, the founder had noticed something felt off with how dates were displaying. No specific bug had been filed. There was a general sense that the timezone handling “wasn’t right.”
What Was Done
The audit didn’t start with assumptions. The agent swept every date operation in the codebase: every gte/lte/gt/lt filter on date columns across src/server/api/routers/, and every date display in the admin UI. The methodology was documented explicitly in the issue, including the grep patterns used.
Each date operation was classified into one of four categories:
- Class A (correct): ~22 occurrences — timezone handling already right, no action needed
- Class B (display smell): ~8 occurrences — cosmetically inconsistent but not functionally wrong
- Class C (latent bugs): ~12 occurrences — incorrect timezone assumptions that would produce wrong results for users outside a specific timezone
- Class D (broken): some occurrences — actively producing incorrect output
The CEO reviewed the audit and responded:
“Excellent work — the audit is rigorous (methodology + grep patterns documented), classification is sound (A/B/C/D with clear rationale), and the 10-PR breakdown groups by code locality so each PR is reviewable in isolation.”
Eight fix PRs were authorized and executed, each scoped to a specific code locality:
- BRO-710: Orders dashboard tiles + monthly export timezone fix
- BRO-711: weekly-sales-email cron Monday gate timezone fix
- BRO-712: Subscription cutoff and next-upcoming timezone fix
- BRO-713: Analytics router timezone rewrite + context threading
- BRO-714: Routes
planRoutetimezone fix - BRO-715: Transactions / Billing / Order exports timezone fix
- BRO-716: Invoice-transaction-fees cron monthly bounds timezone fix
- BRO-717: Admin UI date display helper sweep
Verifiable Outcome
| Metric | Value | Source |
|---|---|---|
| Audit document | Published on BRO-709 | BRO-709#document-audit |
| Class A (correct) | ~22 | Audit document |
| Class B (display smell) | ~8 | Audit document |
| Class C (latent bugs) | ~12 | Audit document |
| Fix PRs executed | 8 | BRO-710 through BRO-717 (child issues, all done) |
| CEO audit verdict | ”Rigorous. Classification is sound.” | Comment on BRO-709 |
| Cycle time | Single day (2026-05-01) | Issue dates |
Why This Story Matters
“The dates seem off” is one of the vaguest bug reports possible. Timezone bugs are notoriously hard to isolate — they often only manifest for users in non-default timezones, they span multiple subsystems, and fixing them surgically without breaking adjacent code requires deep familiarity with the codebase.
The agent turned a vague smell into a classified, documented, prioritized punch list — with explicit methodology and grep patterns that the CEO could verify — and then fixed every class C and D bug in 8 targeted PRs. The PR scoping by code locality was deliberate: each PR was independently reviewable, which meant the CEO could spot-check any fix without needing to understand the full sweep.
The methodology documentation is the detail worth noting: the agent didn’t just produce findings, it produced reproducible findings. A future auditor could run the same grep patterns and verify the same classification logic.